[Python-Dev] closure semantics

[Guido van Rossum]

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

Eek.  Global statement inside flow control should be deprecated, not
abused to show that global is evil. :-)

> Plus. EVERY newbie makes the mistake of taking "global" to mean
> "for ALL modules" rather than "for THIS module",

Only if they've been exposed to languages that have such globals.

> uselessly using global in toplevel,

Which the parser should reject.

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

I think it's not unreasonable to want to replace global with attribute
assignment of *something*.  I don't think that "something" should have
to be imported before you can use it; I don't even think it deserves
to have leading and trailing double underscores.

Walter suggested 'global.x = 23' which looks reasonable; unfortunately
my parser can't do this without removing the existing global statement
from the Grammar: after seeing the token 'global' it must be able to
make a decision about whether to expand this to a global statement or
an assignment without peeking ahead, and that's impossible.

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

If we removed global from the language, how would you spell assignment
to a variable in an outer function scope?  Remember, you can *not* use
'outer.x' because that already refers to a function attribute.

--Guido van Rossum (home page: http://www.python.org/~guido/)