[Python-Dev] statically nested scopes

[Tim Peters]

[Jeremy]
> I agree that visual inspection is a tad harder, but I contend that
> existing programs that use the same name for a global variable and a
> local variable -- and intend for the global to be visible within a
> function nested in the local variable's region -- are confusing.
> It's too hard for a first-time reader of the code to figure out what
> is going on.
>
> Incidentally, I have yet to see an example of this problem occurring
> in anyone's code.  All the examples seem a bit contrived.  I wonder if
> anyone has an example in existing code.

I wasn't the one making the "will break code" argument (I'm sure it will,
but very little, and not at all for most people since most people never nest
functions in Python today apart from default-abusing lambdas).  Visual
inspection stands on its own as a potential problem.

>   [My SICP example omitted]
>
>   TP> Unfortunately for proponents, this is exactly the kind of SICP
>   TP> example that is much better done via a class.
>
> Indeed, the PEP says exactly that: This kind of program is better
> done via a class.  My intent was not to show a compelling use of
> mutable state.  Instead it was to show that with read-only access,
> people could still modify values on enclosing scopes.  The issue is
> whether the language allows the programmer to express this intent
> clearly or if she has to jump through some hoops to accomplish it.

Guido said "jump through some hoops", so I'm dropping it, but first noting
that "the container" in *idiomatic* Python will most often be "self":

    def yadda(self, ...):
        def whatever(amount):
            self.balance += amount
        return whatever

will work to rebind self.balance.  I don't think Guido will ever be
interested in supporting idiomatic Scheme.

>   TP>     def deposit(amount):
>   TP>         global bank_account.balance
>   TP>         balance += amount

> I'm still not sure I like it, because it mixes local variables of a
> function with attribute access on objects.  I'll add it to the
> discussion in the PEP (if Barry approves the PEP <wink>), though.

Actually, no connection to attribute access was intended there:  it was just
a backward-compatible way to spell the pair (name of containing scope, name
of vrbl in that scope).

    global back_account:balance
or
    global balance from bank_account

would do as well (and maybe better as they don't imply attribute access; but
maybe worse as they don't bring to mind attribute access <wink>).

> Do you have any opinion on the subtleties?  The two that immediately
> come to mind are: 1) whether the function's local are available as
> attributes anywhere or only in nested scopes

I didn't intend attribute-like access at all (although we had earlier talked
about that wrt JavaScript, I didn't have that in mind here).

> and 2) whether you can create new local variable using this notation.

Yes, that's the primary one I was thinking about.