[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