Import File Madness

[Gordon McMillan]

jsolbrig at my-deja.com wrote:

> Several Questions/Comment on the python import statement
> 
> 1: Once a python application is large and various classes have
> static member objects of different types, import statements seem
> to have a similar logic to C include files. I.E., the question of
> what order to do the include becomes non-trivial. Is there anyway
> around this or ways to escape this?

I'm not understanding your first sentence.

import is easier than #include. For one thing, the first import of 
a module does all the work and installs it in sys.modules. 
Subsequent imports just get a reference from sys.modules.

For another, unless you're using "from ... import ..." you're 
effectively creating mount points, and changes wrought by 
other modules will be visible.
 
> 2: The import order/mechanism seems to be slightly different in
> different variations of python - WinNT vs. Unix

The search path (sys.path) is built differently, but the import 
mechanism is the same.
 
> 3: It would be nice to some equivalent of "forward definitions" -
> statements would let you construct a static element of type X
> before you have imported the file with X in it.

Ah, you are doing "from ... import ...". Don't do that.
 
> 4: There seem to simply be bugs in the import mechanism which can
> cause modules to be None after being imported intermitantly. Is
> this known, is that this some "feature"? Is this my imagination?
> It seems to happen in large applications - 200K source code.

Never seen it, never heard of it, unless you're using "from".

from Module import Variable

causes the current Module.Variable to be bound to the name 
Variable in your namespace. Subsequent assignments to 
Module.Variable outside your namespace won't be visible 
inside your namespace. They would, if you'd used "import 
Module" and referenced "Module.Variable".

- Gordon