RetroSearch Browse

Thu Oct 23 18:06:58 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-October/039402.html

[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/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/039402.html below:

[Python-Dev] Re: closure semantics