Nested scopes and lexical closures

[Tim Peters]

[Alex Martelli, on rebinding non-local vrbls in nested scopes]

> Only Guido knows, but I suspect he doesn't mean to.

Not if he doesn't "have to", no.  Very few people asked for nested scopes
before lambda snuck into the language, but then the demands zoomed, due to
the unbearable inability of lambda expressions to "see" the vrbls in code
right next to them.  *Re*binding isn't possible in a lambda anyway (all
rebinding contexts in Python are attached to stmts, and lambdas can't
contain stmts), so the hope is we'll be back to an easily overlooked trickle
of intemperate demands from unreformed Scheme-heads.

OTOH, Jeremy Hylton implemented nested scopes, and he's an MIT alum, so if
he's an unreformed Scheme-head in theory if not in practice.  If a
compelling syntax had appeared, I bet he would have pushed hard for it.

Guido continues to believe that mutable state is much better modeled by
classes, so he's not going to change anything here without intense pressure.

> ...
> I thought the Java rule might be better: when a variable named
> X is bound in an enclosing block, an inner block CANNOT define
> a variable named X -- neither bind a new one nor rebind the
> one in the outer block.  This would not change functionality
> (you'd just have to change names of new variables in inner
> blocks whose names conflict with outer-block variables), but
> I thought it would avoid the slight confusion that comes with
> the present situation, where one THINKS one's re-binding an
> outer-block variable but is in fact binding a new local homonym
> that shadows (hides) the outer one.

OTOH, Java allows locals to shadow class members, and that's a source of
bugs too -- and somtimes worse, because the class members' declarations may
be physically far removed.  BTW, the most frequent blind spot in my C++ days
was using an editor to copy (e.g.)

    int numFrobnicators;

from the class decl into a new method, *intending* to write e.g.

    numFrobnicators = 0;

in the latter, but then leaving the "int " in by mistake:

    int numFrobnicators = 0;

C++, like Java, is happy with that, and the resulting code is a disaster.

In Pythonland, the internal PythonLabs debate over shadowing rules
floundered over what to do about the builtins.  In a real sense, they're in
an enclosing scope too, but billions (yes, I counted <wink>) of functions do
something like

    str = first + last

"list" is also routinely rebound.  So the idea hit a snag:  making an
exception for builtins would have been at least a little ugly, but not
excepting them would have caused howls of protest.

> ...
> Anyway, I don't think my musings of the time were very
> much listened to.

I believe Guido was aware of them; I know I was.

> Some people can't stand my style, and, alas, it appears our beloved
> BDFL belongs to that unlucky minority

Guido loves you!  But he has very little time for debate, while your
debating budget exceeds the ambitions of most third-world economies <wink>.

> (not too sure it IS a minority, but they're surely unlucky for
> their unfortunate dislikes, aren't they:-).

Indeed they are.

although-most-times-nesting-is-still-for-the-birds-ly y'rs  - tim