Re: Dictionaries in Python

Steven D. Majewski (sdm7g@elvis.med.virginia.edu)
Tue, 23 Aug 1994 19:51:26 -0400

On Aug 23, 15:27, Michael Powers wrote:
>
> FILE a.py LOOKS LIKE
>
> yes = "yes"
> no = "no"
>
> from b import *
>
> main()
>
>
> FILE b.py LOOKS LIKE
>
> def main():
> print yes
> print no
>
>
> The problem is that yes and no are not found inside of the main function.
> How do I share global variables between separate files?? In my case I am
> trying to define classes and instances within different .py files that need
> to refer to some central services that are instantiated within one central
> file. I would rather not have to pass these as arguments to each method.
> There IS a reason for this, trust me.
>

Both modules have to mutually import each other: a must import b,
and b must import a.

# --- a.py contains:
y = "yes"
n = "no"

from b import *
main()

# --- b.py contains:
from a import *

def main():
print y
print n

$ python -c 'import a'
yes
no

BTW: This is just the sort of code in which I wouldn't recommend
indiscriminate use of "from module import *", but I'm following your
lead to show that it can be done. This sort of mutual recursion is
just crying out for fully qualified names:
"import a; ... print a.y; print a.n"
is less confusing, I think!

Mutually recursive imports are not an infinite regress problem.

A module's code is actually executed only on the first import.
( or a "reload(modname)" )

All other import statements for that module do not execute code, but
do affect the namespace, i.e. they make the names created by the
previous execution of that module visible.

People don't seem to have this difficulty understanding the module
system in Modula-2, for example, because it is compiled, not
interpreted, so they do not worry about the side effects of an import.

But in Python, even definitions ( 'def' & 'class' ) are executable
statements that execeute code and that has the side effect of defining
a name in a dictionary. 'import' sometimes executes code and sometimes
doesn't. ( 'global' is the only non-executable 'pure' declaration I can
think of, off the top of my head. Any others ? )

Briefly ( and not peeking at the source code, so I probably have something
out of order. If you've really got to know exactly, look at import.c. )
what "import module" does (more or less) is:

Is this the first import for a module ? ( Is it not in sys.modules list? )
is it builtin ( in sys.builtin_module_names ) ?
execute modules init routine
else, is dynamic loading is supported and is there a .so file ?
load object module
execute modules init routine
else, is there a .py file ?
is there not a .pyc file younger than .py file ?
compile .py file into a code object
( and marshall it out-to new .pyc file )
create an (empty) module
execute code object using new module's dict namespace
[ This has the side effect of filling the module's
namespace dictionary with objects. ]
For "import module", enter the module into the calling modules dictionary.
For "from module import ... " enter the objects from module into
calling modules dictionary.

There is one piece of code ( for builtin or dynamically loadable
object modules, the module's init code, for python modules, a single
marshalled (byte) code object ) that is executed (on the initial
'import' ) for the side effect of dynamically creating all of the
objects in the module's dictionary

- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics