Nested scopes and lexical closures

Alex Martelli aleaxit at yahoo.com
Mon Aug 20 03:57:27 EDT 2001


"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.998290590.13404.python-list at python.org...
    ...
> 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.

FWIW, I do agree that classes are a better tool for this.  The best use
I've found so far for nested-scopes is a better way to express currying,
and that doesn't need any rebinding ability.  My only issue with the
current rules is that they're somewhat surprising/unexpected.  Maybe
a warning about local-shadowing-outer would do as well as a total
prohibition.


> > 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
    ...
> 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

Good point -- Python, of course, finesses the issue thanks to the
wonderful decision that members are explicitly accessed AS members
(self.whatever, &c).


> 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.

I agree the issue is relevant, but builtins aren't "lexically" enclosing --
they're more of a "namespace of last resort".  Breaking all code that
happens to bind a builtin name in local or module scope would have
been tantamount to adding a zillion new keywords at a stroke -- the
howls of protest would have been amply justified.  Again, maybe,
warnings (which can be turned off) could be a good compromise.


Alex






More information about the Python-list mailing list