>> 'global' vars [ 'in' named_scope ] >> >> where named_scope can only be the name of a function which encloses >> the function containing the declaration.
Guido> That was my first suggestion earlier this week. The main Guido> downside (except from propagating 'global' :-) is that if you Guido> rename the function defining the scope you have to fix all global Guido> statements referring to it.
Well, the listed variables are "global" to the current local scope. I find the rename argument a bit specious. If I rename a function I have to change all the references to it today. This is just one more. Since "global" is a declarative statement, the compiler can tell you immediately that it can't find the old function name.
Guido> I saw a variant where the syntax was
Guido> 'global' vars 'in' 'def'
Guido> which solves that concern (though not particularly elegantly).
I don't see how that can work though. What does 'def' mean in this case? There can be multiple lexically enclosing functions, any of which have the same local variable x which you might want modify.
>> 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.
Guido> Definitely compile time. 'f' has to be a name of a lexically Guido> enclosing 'def'; it's not an expression. The compiler nees to Guido> know which scope it refers to so it can turn the correct variable Guido> into a cell.
Okay, that was easily settled. ;-)