[Python-Dev] Re: closure semantics
Guido van Rossum
guido at python.org
Thu Oct 23 18:06:58 EDT 2003
[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/)
More information about the Python-Dev
mailing list