Before it is reasonable to change the meaning of "global", we would
need to have coherent answers to these questions:
1. What is the global namespace?
2. Do global variables belong to the global namespace?
3. When it says "global x" does that mean x is a global variable?
I think the folks who support changing "global" to mean "innermost
existing nonlocal" really have to provide answers to these. They
are bound to become FAQs the moment such a change takes place.
Can you imagine trying to teach this?
My main problem with changing the meaning of "global" is that doing
so causes one of these answers to be nonsense. Maybe i fail to see
where our trains of thought diverge. It seems to me, either you have
to say (#1) there is no longer such a thing as "the global namespace",
or (#2) global variables have nothing to do with the global namespace,
or (#3) "global x" has nothing to do with whether x is global.
In all cases, well established Python terminology is thrown into
confusion. It'll be even worse if we don't all agree on *which* of
these three answers to make nonsense -- if we don't all choose the
*same* nonsense, no one will know what anyone means by "global
variable". The phrase "the global namespace" becomes meaningless or
fraught with ambiguity.
Or, in a concrete example:
def f():
n = 2
def spam():
global n = 99
spam()
1. Is the "n" affected by spam() a global variable?
2. In what namespace does this "n" reside?
3. Is that what you would call the "global namespace"?
4. If not, which namespace is the "global namespace"?
(You can't just say "oh, no one will ever write code like that."
There have to be sensible answers -- teaching examples look like
this, and tests test this, and curious students will want to know.)
If the intention is to persuade Python programmers that the word
"global" could refer to any of several namespaces, that would break
compatibility not just with earlier versions of the language but
with all the documentation and educational materials out there that
mention "global variable" or "global namespace".
Parts of the reference manual and even the codebase would also
become confusing or misleading as a result -- identifiers containing
the word "global" or comments mentioning the "global namespace"
would no longer make sense.
That seems like a lot of unnecessary work and a losing battle, IMHO.
The battle will only hurt Python users who, henceforth, whenever
they hear "global" can no longer tell which namespace you're
talking about.
And what are we gaining for this cost? So far there's no positive
argument that "global" is actually the right word for this purpose --
defenders of "global" only seem to be saying that it's not a totally
awful word for this purpose. Why tolerate something that is merely
barely understandable (if you try hard enough to ignore what the rest
of the world means by "global"), just to save a keyword? This is a
new kind of variable access for Python; it deserves a new keyword.
(Though "nonlocal" is my preference, i would take just about anything
over "global".) I thought Py3K was about a fresh chance to make good
choices, instead of getting by with tolerable ones.
-- ?!ng
_______________________________________________
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
