>> '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. ;-) Skip