[Python-Dev] PEP for Better Control of Nested Lexical Scopes
Ron Adam
rrr at ronadam.com
Tue Feb 21 16:48:21 CET 2006
Jeremy Hylton wrote:
> On 2/21/06, Jeremy Hylton <jeremy at alum.mit.edu> wrote:
>> I had to lookup top-post :-).
>>
>> On 2/21/06, Bengt Richter <bokr at oz.net> wrote:
>>> On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <jeremy at alum.mit.edu> wrote:
>>>> Jeremy
>>> Hey, only Guido is allowed to top-post. He said so ;-)
>> The Gmail UI makes it really easy to forget where the q
>
> Sorry about that. Hit the send key by mistake.
>
> The Gmail UI makes it really easy to forget where the quoted text is
> in relation to your own text.
>
>>> But to the topic, it just occurred to me that any outer scopes could be given names
>>> (including global namespace, but that would have the name global by default, so
>>> global.x would essentially mean what globals()['x'] means now, except it would
>>> be a name error if x didn't pre-exist when accessed via namespace_name.name_in_space notation.
>
> Isn't this suggestion that same as Greg Ewing's?
>
>>> namespace g_alias # g_alias.x becomes alternate spelling of global.x
>>> def outer():
>>> namespace mezzanine
>>> a = 123
>>> print a # => 123
>>> print mezzanine.a # => 123 (the name space name is visible and functional locally)
>>> def inner():
>>> print mezzanine.a => 123
>>> mezznine.a =456
>>> inner()
>>> print a # = 456
>>> global.x = re-binds global x, name error if not preexisting.
>>>
>>> This would allow creating mezzanine like an attribute view of the slots in that local namespace,
>>> as well as making namespace itself visible there, so the access to mezzanine would look like a read access to
>>> an ordinary object named mezzanine that happened to have attribute slots matching outer's local name space.
Why not just use a class?
def incgen(start=0, inc=1) :
class incrementer(object):
a = start - inc
def __call__(self):
self.a += inc
return self.a
return incrementer()
a = incgen(7, 5)
for n in range(10):
print a(),
7 12 17 22 27 32 37 42 47 52
Cheers,
Ronald Adam
More information about the Python-Dev
mailing list