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

Thomas Wouters thomas at xs4all.net
Tue Feb 21 15:27:54 CET 2006


On Tue, Feb 21, 2006 at 08:02:08AM -0500, Jeremy Hylton wrote:

> The lack of support for rebinding names in enclosing scopes is
> certainly a wart.  I think option one is a better fit for Python,
> because it more closely matches the existing naming semantics.  Namely
> that assignment in a block creates a new name unless a global
> statement indicates otherwise.  The revised rules would be that
> assignment creates a new name unless a global or XXX statement
> indicates otherwise.

I agree with Jeremy on this. I've been thinking about doing something like
this myself, but never got 'round to it. It doesn't make working with
closures much easier, and I doubt it'll encourage using closures much, but
it does remove the wart of needing to use mutable objects to make them
read-write.

> The names of naming statements are quite hard to get right, I fear.  I
> don't particularly like "use."  It's too generic.  (I don't
> particularly like "scope" for option 2, either, for similar reasons. 
> It doesn't indicate what kind of scope issue is being declared.)  The
> most specifc thing I can think of is "free" to indicate that the
> variable is free in the current scope.  It may be too specialized a
> term to be familiar to most people.

I was contemplating 'enclosed' as a declaration, myself. Maybe, if there's
enough of a consent on any name before Python 2.5a1 is released, and the
feature isn't going to make it into 2.5, we could ease the introduction of a
new keyword by issuing warning about the keyword in 2.5 already. (Rather
than a future-import to enable it in 2.6.) Maybe, and only if there's no
doubt about how it's going in, of course.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!


More information about the Python-Dev mailing list