in reply to Nesting Functions

from my understanding is a nested def in Python equivalent to °

sub outer {
   my $c_inner = sub { print "perl" };
   $c_inner->();
}

[download]

Please note that Python is implicitly preferring references while Perl prefers the "Explicit is better than implicit" approach (yes it's ironic)

> Python has Local, Enclosing, Global and Built-in variables.

More or less: *

> It was this video that promoted my thinking on this. https://www.youtube.com/watch?v=QVdf0LgmICw

Not linkified not watched.²

Hint: Please provide code examples if you want better answers.

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

update

°) There was an experimental attempt to allow "private subs" in Perl, which was essentially syntactic sugar for the following IIRC. No idea if it's still available or deprecated.

*) the py-docs are sparse and incomplete here. Variable declarations in class context become attributes. These are essentially package vars in Perl. (Python has no package and Perl has no class )

²) tried to, but won't watch a 20 min video to guess what your question is.

³) updated, see Re^7: Nesting Functions for details

Replies are listed 'Best First'.
Re^2: Nesting Functions
by choroba (Cardinal) on Jul 19, 2019 at 12:05 UTC
    > No idea if it's still available or deprecated

    Upgrade! They are no longer experimental and they can be nested. Lexical Subroutines

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]
      The docs are (as usual) fuzzy, is it the same semantic like the code I've shown?

      I.e. will PadWalker show an entry inner for my sub inner {} ?

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

[reply]
[d/l]
[select]
Re^2: Nesting Functions
by Eily (Monsignor) on Jul 19, 2019 at 12:34 UTC

    Local and enclosing are lexical my
    Python doesn't have lexicals. All variables are rather some equivalent of package variables, where each function counts as a package that can't access variables of other function. So a variable can be used as long as it as been defined sometime before in the function, regardless of scope:
    >>> def scope():
...     for x in range(1,10):
...             if x > 3:
...                     print(a)
...             else:
...                     a=x
...
>>> scope()
3
3
3
3
3
3
>>> print(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined

    [download]
    I had some difficulty understanding the meaning and use of with statements, until I realized it was just a mechanism to simulate lexical scope (with the possibility to do some clean up on a variable at the end of a defined scope). You might find some example when looking for variable declaration in python, but actually the (new) feature is just type enforcing, there is no equivalent to my in python.

    That's the thing I dislike the most about python, just above the lack of explicit block-ending tokens (curly brackets :P).

[reply]
[d/l]
      > All variables are rather some equivalent of package variables, where each function counts as a package that can't access variables of other function.

      That's more or less how lexicals are realized in Perl.

      A Pad° is a hash like structure ("namespace") like a package. (with the difference that it doesn't have globs)

      Every scope has it's own pad, nesting scopes results in a chain of pads to be investigated.

      You may want to play a bit with PadWalker

      > Python doesn't have lexicals.

      Python has closures, closures require lexicals.

      > there is no equivalent to my in python.

      Implementation of semantic matters not syntax or naming.

      update

      the first assignment in a "scope" is an implicit declaration in Python.

      Sometimes it's a my sometimes an our .

      The mess starts because you can't use something like strict* to catch typos and Py3 needed to introduce nonlocal to mark assignments which are not declarations.

      "Explicit is better than implicit" ... LOL

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      °) Pad: = short for perlguts#Scratchpads

      *) which JS successfully copied because it has var and even let now.

[reply]
[d/l]
[select]

        Implementation of semantic matters not syntax or naming.
        I'm not sure I understand what you mean. Are you saying the names of elements in a language must match their implementation and not their behaviour? I really don't agree with that, you shouldn't have to know which interpreter you are using to call things, if their behaviour is well defined.

        If you do call python's function variables lexical, I surely wouldn't call them "lexical my", as you can't limit a variable to a scope except function (so a variable in a loop can be used outside of that loop). And the condition for using a variable in perl is that it has been declared before lexically, while in python it must have been defined before chronologically. Also in perl one distinction is that non lexicals can be accessed by name (symref or symbols table) while lexicals can't. Python doesn't have that distinction.

        Python has closures, closures require lexicals.
        I'm tempted to argue that it could also be that Python has a different definition of closure, but I think that's a fair point. But Python variables behave so differently than lexicals from other languages (at least the ones I know), that I'd rather avoid calling them lexicals, and focus on the fact that closures keep a hold of variables beyond their expected lifespan, rather than talking about lexical scope.

        Edit: (after yours):

        the first assignment in a "scope" is an implicit declaration in Python.
        I'd rather consider that all possible variables are implicitly declared. Otherwise that would mean that you can access a variable above it's (implicit) declaration like in my example. This would also imply conditional declaration when I'd rather consider only the definition/initialization can be conditional. Although, after checking, exec (the equivalent of perl's eval) only sees globals by default. So that's a point for lexicals.

[reply]
        > The mess starts because you can't use something like strict* to catch typos and Py3 needed to introduce nonlocal to mark assignments which are not declarations.

        Another disturbing thing is that Python does hoisting like JS.

        if it encounters a (implicit) declaration of a var somewhere at the end of a function, it will bind all var to the same private storage.

        see demo of the mess in fun2()

        >>> a=666       # global
>>> def fun1():
...    print a  # global
... 
>>> def fun2():
...    print a  # privat
...    a = 33   # declaration
... 
>>> fun1()
666
>>> fun2()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in fun2
UnboundLocalError: local variable 'a' referenced before assignment
>>>

        [download]

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom