[Python-Dev] closure semantics

Alex Martelli aleaxit at yahoo.com
Tue Oct 21 19:21:52 EDT 2003


On Wednesday 22 October 2003 00:51, Guido van Rossum wrote:
   ...
> Maybe "global x in f" would work?

Actually, I would rather like to DO AWAY with the anomalous 'global'
statement and its weird anomalies such as:

x = 23

def f1(u):
    if u:
        global x
    x = 45

def f2():
    if 0:
        global x
    x = 45

print x
f2()
print x
f1(0)
print x

"if u:" when u is 0, and "if 0:", should have the same effect to avoid
violating the least-astonishment rule -- but when the if's body has
a global in it, they don't.  Eeek.

Plus. EVERY newbie makes the mistake of taking "global" to mean
"for ALL modules" rather than "for THIS module", uselessly using
global in toplevel, etc.  It's a wart and I'd rather work to remove it
than to expand it, even though I _would_ like rebindable outers.

I'd rather have a special name that means "this module" available
for import (yes, I can do that with an import hook today).  Say that
__this_module__ was deemed acceptable for this.  Then,
    import __this_module__
    __this_module__.x = 23
lets me rebind the global-to-this-module variable x without 'global'
and its various ills.  Yeah, the name isn't _too_ cool.  But I like the
idea, and when I bounced it experimentally in c.l.py a couple weeks
ago the reaction was mildly positive and without flames.  Making
globals a TAD less handy to rebind from within a function would
not be exactly bad, either.  (Of course 'global' would stay until 3.0
at least, but having an alternative I could explain it as obsolescent:-).

Extending this idea (perhaps overstretching it), some other name
"special for import" might indicate outer scopes.  Though reserving
the whole family of names __outer_<name>__ is probably overdoing
it... plus, the object thus 'imported' would not be a module and would
raise errors if you tried setattr'ing in it a name that's NOT a local
variable of <name> (the import itself would fail if you were not lexically
nested inside a function called <name>).  Thus this would allow
*re-binding* existing local outer names but not *adding* new ones,
which feels just fine to me (but maybe not to all).

OK, this is 1/4-baked for the closure issue.  BUT -- I'd STILL love
to gradually ease 'global' out, think the "import __this_module__"
idea is 3/4-baked (lacks a good special name...), and would hate
to see 'global' gain a new lease of life for sophisticated uses...;-)


Alex




More information about the Python-Dev mailing list