[Python-Dev] PEP for Better Control of Nested Lexical Scopes (original) (raw)

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