At 11:50 PM 2/21/2006 +0100, Morel Xavier wrote: >Phillip J. Eby wrote: >>The '.' would mean "this name, but in the nearest outer scope that >>defines it". Note that this could include the global scope, so the >>'global' keyword could go away in 2.5. And in Python 3.0, the '.' could >>become *required* for use in closures, so that it's not necessary for the >>reader to check a function's outer scope to see whether closure is taking >>place. EIBTI. > >While the idea is interesting, how would this solution behave if the >variable (the name) didn't exist in any outer scope?
The compiler should consider it a name in the global scope, and for an assignment the name would be required to have an existing binding, or a NameError would result. (Indicating you are assigning to a global that hasn't been defined.) >Would it create and bind the name in the current scope? No, never. > If yes, why wouldn't this behavior become the default (without > any leading dot), efficiency issues of the lookup? No, it would be because explicit is better than implicit. The whole point of requiring '.' for closures in Python 3.0 would be to keep the person who's reading the code from having to inspect an entire function and its context to figure out which names are referring to variables in outer scopes. That is, it would go against the whole point of my idea, which is to make explicit what variables are part of your closure. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
