Global variables and modules

[Alex Martelli]

<dkeeney at travelbyroad.net> wrote:
   ...
> and here is the test script, test1.py
> -------------------------------------
> 
> from test2 import glbl, inc_glbl, get_glbl

Think of this as roughly equivalent to:

import locl
glbl = test2.glbl

and so on.  That is, after the 'from test2 import', the two names
test1.glbl and test2.glbl refer to the same object.  But if you now
rebind name test2.glbl to refer to a distinct object, that of course has
no effect on name test1.glbl.

> I would expect the three values to be ( 25, 26, 26 ), but what I get is

Why?  Take an equivalent:

a = 25
b = a
a = 26

would you now expect name b to be magically rebound to 26?  If so, then
you have a very peculiar mental model for name/value correspondences,
one that doesn't happen to hold in any language I know, surely not in
Python.  To repeat a commonly used metaphor: think of names as post-it
notes that may be attached to some piece of furniture, and moved from
one to another.  The notes are NOT attached to each other, but rather to
the objects: moving one post-it does not affect other post-its.

> It seems that the references to 'glbl' are seeing a local copy, rather

No copy whatsoever is involved.  After the assignment (binding) you do
with 'from test2 import', names test1.glbl and test2.glbl refer to the
same object (value).  If you now rebind either name, the other is
unaffected.

> than the original.  This is not what the literature says should be
> happening.

If you can point to sentences in "the literature" which have misled you
into believing a different behavior would be expected, I'll do my best
to fix those sentences (as a book and article author, editor, reviewer,
and Python contributor).  While the Python docs, including books &c, are
far from perfect, I doubt there is any such blooper left in them.

> I am looking for a way to share data between modules.  Can

If you really must, consider using a container object.  The most
suitable container object for these tasks is often a module.  I.e.,
code, in test1:

import test2

and then refer to test2.glbl throughout.  I.e., forget 'from', use
'import'.

As I wrote in Python in a Nutshell, p. 120, last paragraph before
"Module Loading":
"""
In general, the import statement is a better choice than the from
statement.  I suggest you think of the from statement [...] as [a]
convenience meant only for occasional use in interactive Python
sessions.  If you always access module M with the statement import M,
and always access M's attributes with explicit syntax M.A, your code
will be slightly less concise, but far clearer and more readable.
"""

I don't know how I could have put this advice more strongly or more
directly (I continue with explanations about the cases in which 'from'
is instead appropriate, chiefly getting single modules from packages).

Giving strong direct advice, rather than just reference info, in a book
of the "in a Nutshell" series, is not common, but I do it quite a bit;
after all, "how does Python work exactly", e.g. the fact that 'from X
import Y' is almost the same as 'Y = X.Y', is pretty simple to explain,
and so takes up little space -- OTOH, the consequences of this, such as
"thus, generally, don't use 'from', use 'import'" may not be obvious to
readers, so I point them out directly.

Of course, that doesn't help much if people don't _read_ it;-).


Alex