Ka-Ping Yee wrote:
> Right now, in any given context, "the global namespace" has a clear
> meaning: the namespace shared by the whole file. With the new meaning
> of the "global" keyword, "global namespace" becomes meaningless no
> matter what the context. In Python, the concepts of "global", "global
> variable", and "global namespace" are too well established to destroy.
Exactly.
A lookup of a bare name can be resolved in one of the following kinds of
namespace:
1. function locals (either the current function or an enclosing function)
2. module globals
3. builtins
The new PEP is about being able to better distinguish the case where the name
is being resolved in an enclosing function's local namespace instead of the
current function's local namespace. Simply moving the ambiguity to the second
entry in the list above is NOT an improvement!
A new keyword, on the other hand, allows the list to be split relatively
cleanly into four possible locations:
1. function locals of the current function (local variables)
2. function locals of an enclosing function (closure variables)
3. module globals (global variables)
4. builtins (builtin names)
A name for the second category other than 'nonlocal' would be nice, but I find
it infinitely preferable to trying to redefine global. The only requirement I
would place on it is that "nonlocal n" when there is no 'n' defined in a
surrounding scope should be a SyntaxError.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
