[Python-Dev] closure semantics

[Guido van Rossum]

[Guido]
> > Maybe "global x in f" would work?

[Jeremy]
> Woo hoo.  I'm happy to hear you've had a change of heart on this topic.
> I think a simple, declarative statement would be clearer than assigning
> to an attribute of a special object.

Right.

> If a special object, like __global__, existed, could you create an
> alias, like:
> 
>     surprise = __global__
>     surprise.x = 1
>     print __global__.x
> 
> ?
> 
> It would apparently also allow you to use a local and global variable
> with the same name in the same scope.  That's odd, although I suppose it
> would be clear from context whether the local or global was intended.

I don't care about that argument; it's no more confusing to have
globals.x and x as it is to have self.x and x, and the latter happens
all the time.

> > def outer():
> >     x = 1
> >     def intermediate():
> >         x = 2
> >         def inner():
> >             global x in outer
> >             x = 42
> >         inner()
> >         print x      # prints 2
> >     intermediate()
> >     print x          # prints 42
> 
> I would prefer to see a separate statement similar to global that meant
> "look for the nearest enclosing binding."  Rather than specifying that
> you want to use x from outer, you could only say you don't want x to be
> local.  That means you'd always get intermediate.

That would be fine; I think that code where you have a choice of more
than one outer variable with the same name is seriously insane.  An
argument for naming the outer function is that explicit is better than
implicit, and it might help the reader if there is more than one
level; OTOH it is a pain if you decide to rename the outer function
(easily caught by the parser, but creates unnecessary work).

I admit that I chose this mostly because the syntax 'global x in
outer' reads well and doesn't require new keywords.

> I think this choice is more modular.  If you can re-bind a non-local
> variable, then the name of the function where it is initially bound
> isn't that interesting.  It would be safe, for example, to move it to
> another place in the function hierarchy without affecting the semantics
> of the program

I'm not sure what you mean here.  Move x around, or move outer around?
In both cases I can easily see how the semantics *would* change, in
general.

> -- except that in the case of "global x in outer" you'd
> have to change all the referring global statements.

Yes, that's the main downside.

> Or would the semantics be to create a binding for x in outer, even
> if it didn't already exist?

That would be the semantics, right; just like the current global
statement doesn't care whether the global variable already exists in
the module or not; it will create it if necessary.  But a relative
global statement would be fine too; it would be an error if there's no
definition of the given variable in scope.

But all this is moot unless someone comes up with a way to spell this
that doesn't require a new keyword or change the meaning of 'global x'
even if there's an x at an intermediate scope (i.e. you can't change
'global x' to mean "search for the next outer scope that defines x").

And we still have to answer Alex's complaint that newbies misinterpret
the word 'global'.

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