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

Almann T. Goo almann.goo at gmail.com
Tue Feb 21 16:12:06 CET 2006

> 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.
>     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.

This seems like a neat idea in principle, but I wonder if it removes
consistency from the language.    Consider that the scope that
declares the namespace and its child scopes the names could be
accessed by the namespace object or the direct name, but *only* in the
child scopes can re-binding for the name be done via the namespace

  def outer() :
    namespace n
    a = 5 # <-- same as n.a = 5
    def inner() :
      print a # <-- same as n.a
      n.a = 7 # <-- *not* the same as a = 7
    print n.a

I don't like how a child scope can access a free variable from an
enclosing scope without the namespace object, but needs to use it for
re-binding.  Because of this, namespace objects have the potential to
obfuscate things more than fix the language issue that I am


Almann T. Goo
almann.goo at gmail.com

More information about the Python-Dev mailing list