Python has a few issues many consider problems with
regard to its variable namespacing.
It seems that the local/global/builtins namespacing
rules are ancient remnants of a different Python.
While function-level, module-level and "builtin-level"
variables are still needed, I suggest a few different
lookup schemes, with different levels of extremity:
A) Only get rid of the assignment-makes-local
heuristic, by changing the meaning of the "global"
keyword:
def f():
global.a = 1 # Assigns to the module.a
a = 2 # Assigns to a local variable
This allows accessing globals, and IMO serves for
better explicitness about variables which is very
desirable and consistent with instance variable
access.
This is not backwards compatible, however this seems
to be entirely statically-convertible (A simple script
can convert old-global notation to the new).
This has a side-effect of "global" now meaning the
"current module" (*1).
B) Create a hierarchy of "locals" for nested scopes,
which are accessible via an overloaded or new keyword
thus:
I)
b = 1
def f():
a = 2
def g():
global.a = 3
global.global.b = 4
II)
b = 1
def f():
a = 2
def g():
parent.a = 3
global.b = 4
C) For consistency and name-lookup simplicity, also
make the builtin-namespace explicit:
import __builtins__ as builtins
builtins.zip(.. .)
or the backwards compatible:
from __builtins__ import *
I personally don't like C, but think A and B are
almost crucial to the "cleanup" of Python's historic
lookup semantics. Please don't rule out all
suggestions (A, B and C) because of a flaw in one of
them.
Awaiting your replies.
*1: For consistency, "class" could be made to mean the
current class without any ambiguity [but perhaps
complicating the parser], dissolving the need to
re-specify the current class name in calls to super,
for example.
_______________ _______________ ____
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
