[Python-Dev] PEP for Better Control of Nested Lexical Scopes

Terry Reedy tjreedy at udel.edu
Tue Feb 21 20:16:17 CET 2006


"Almann T. Goo" <almann.goo at gmail.com> wrote in message 
news:7e9b97090602210516o5d1a823apedcea66846a271b5 at mail.gmail.com...

> I certainly hope that an initiative like this doesn't get stymied by
> the lack of a good name for such a keyword.  Maybe something like
> "outer"?

Adding a keyword has a cost that you have so far ignored.  Guido is 
rightfully very cautious about additions, especially for esthetic reasons.

The issue of rebinding enclosed names was partly discussed in PEP 227. 
Sometime after the implementation of the PEP in 2.1, it was thoroughly 
discussed again (100+ posts?) in this forum.  There were perhaps 10 
different proposals, including, I believe, 'outer'.  Guido rejected them 
all as having costs greater than the benefits.  Perhaps you can find this 
discussion in the archives.  I remember it as a Jan-Feb discussion but 
might be wrong.

This thread so far seems like a rehash of parts of the earlier discussion. 
In the absence of indication from Guido that he is ready to reopen the 
issue, perhaps it would better go to comp.lang.python.  In and case, 
reconsideration is more likely to be stimulated by new experience with 
problems in real code than by repeats of 'orthogonality' desires and 
rejected changes.

---

In another post, you rejected the use of class instances by opining:

>Because I think that this is a workaround for a concept that the
>language doesn't support elegantly with its lexically nested scopes.

>IMO, you are emulating name rebinding in a closure by creating an
>object to encapsulate the name you want to rebind

Guido, on the other hand, views classes and instances as Python's method of 
doing what other (functional) languages do with closures.  From the PEP:
    "Given that this
    would encourage the use of local variables to hold state that is
    better stored in a class instance, it's not worth adding new
    syntax to make this possible (in Guido's opinion)."
He reiterated this viewpoint in the post-PEP discussion mentioned above.  I 
think he would specificly reject the view that Python's alternative is a 
'workaround' and 'emulation' of what you must consider to be the real 
thing.

Terry Jan Reedy






More information about the Python-Dev mailing list