[Skip]
Given that the global keyword or something like it is here to stay (being preferable over some attribute-style access)
(Actually I expect more pushback from Alex once he's back from his trip. He seems to feel strongly about this. :-)
and that global variable writes needs to be known to the compiler for future efficiency reasons, I think we need to consider modifications of the current global statement. The best thing I've seen so far (I forget who proposed it) is
'global' vars [ 'in' named_scope ]
where named_scope can only be the name of a function which encloses the function containing the declaration.
That was my first suggestion earlier this week. The main downside (except from propagating 'global' :-) is that if you rename the function defining the scope you have to fix all global statements referring to it. I saw a variant where the syntax was 'global' vars 'in' 'def' which solves that concern (though not particularly elegantly).
In Greg's example of inc_x_by nested inside f, he'd have declared:
global x in f
in inc_x_by. The current global statement (without a scoping clause) would continue to refer to the outermost scope of the module.
This should be compatible with existing usage. The only problem I see is whether the named_scope needs to be known at compile time or if it can be deferred until run time.
Definitely compile time. 'f' has to be a name of a lexically enclosing 'def'; it's not an expression. The compiler nees to know which scope it refers to so it can turn the correct variable into a cell. --Guido van Rossum (home page: http://www.python.org/~guido/)