You are figuring out the obscure parts of Python at an amazing
speed... You actually discovered something that I can't explain!
Indeed the documentation isn't very clear about globals except for
that one passage in misc/CLASSES.
The *real* *deep* reason why there is no global assignment is that
there is no static symbol table listing all names of known local and
global variables (really "name bindings" in the standard jargon that
I'm trying to establish for discussing these issues). If the
interpreter encounters a statement "x = 1" it has no idea whether
there is a global x this might refer to, so the assignment is always
made local. If there is *already* a global by this name it is
possible to find out (by just looking it up in the global name space),
but this would still prohibit creating new globals from within a
function. I also thought that local variables would be in the
majority, and disliked the possibility that using a local variable
like "i" would accidentally clash with a global also named "i".
Therefore I decided that all variable assignments were to be local.
Variable references don't face the same problems, so they use a
local-scope-first rule; read-only acces to globals is essential
because (most) functions and imported modules are global name bindings.
The code generator (which didn't exist in very early versions of
Python) adds a little subtlety: it actually builds a list of local
variables by finding all name binding statements, and then generates
code that uses this fact throughout the function, distinguishing
between local and global lookups. (The reason for this, BTW, is to
speed up global name lookups so that they don't first have to miss in
the local name set.) This explains your incK() errors. I was
surprised that this didn't break your earlier decN() example;
apparently the code generator generates different code, that uses the
old local-before-global rule when the global scope is the user's
workspace. (Another way to trigger this is to write from
<some-module> import *; here the compiler can't figure out what the
local names will be. But I think it's a bug here.)
You're right that a way of faking global variables is to lock them all
up in a class instance, and there are several demo programs that use
this trick (e.g., mclock). Object-oriented design can usually avoid
the need for global variables in the first place.
But I still think that for simple programs the global variable
assignment has the merit of simplicity and relative elegance, and
actually I am thinking about introducing a 'global' statement with
which you can declare that names you are using in a function are
actually references to globals. This statement would be placed
inside the function body that uses the globals. Python's main source
of inspiration, ABC, has a similar statement (SHARE), and I think I
saw it in one of its competitors (Tcl) as well. (What's Perl's
attitude towards locals and globals? I forgot...)
BTW, the user's workspace is not super-global. (Module 'builtin',
containing the built-in functions and exceptions, is.) If you really
need to access the user's workspace from a module, import __main__.
--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"Well I'm a plumber. I can't act"