Importing and namespace visibility

[jean-marc]

As an application programmer, I'm not well versed in the material
aspects of computing (memory, cpu, bus and all). My understanding of
imports in Python is such: the __main__ program is the center piece
which holds the programs reference: globals, functions, classes,
modules etc. The objects of this file (functions and classes) are
directly accessible; 'import suchModule' s objects are attainable
through the *qualified name* (module.function); the 'from suchModule
import *' the objects are directly attainable.

A recent msg from F. Lundh
http://groups.google.ca/group/comp.l...51ab24748251d8
suggested being careful with recursive importing...

BUT, of all this I thought that if you import module1, then module2
(into __main__), objects from module1 would be available to objects of
module2 which came (into memory space) after module1 was loaded. This
does not seem to be the case, and module2 requires an 'import module1'
statement in its own file to see this last module's objects. This is
not the recursive situation that was a pitfall Fredrik was evoking.
What am I missing here???

The reason I'm asking is to setup team development, using Tkinter,
where different people will be programming diverse sections to be
'packed' into the main interface...

Thanks for any help in understanding what is happening in this
situation,

JMD

[Fredrik Lundh]

"jean-marc" wrote:

BUT, of all this I thought that if you import module1, then module2
(into __main__), objects from module1 would be available to objects of
module2 which came (into memory space) after module1 was loaded. This
does not seem to be the case, and module2 requires an 'import module1'
statement in its own file to see this last module's objects. This is
not the recursive situation that was a pitfall Fredrik was evoking.
What am I missing here???

importing something into a module only makes the names available in
that module, not in every other module. (import is not some kind of
global include). for the details, read the "There are Many Ways to
Import a Module" section under:

http://effbot.org/zone/import-confusion.htm

(and as mentioned under "What Does Python Do to Import a Module",
importing a module twice doesn't load the module again; it only makes
the name(s) available to the importing module).

reading the following sections in the language reference may also help:

http://docs.python.org/ref/naming.html
http://docs.python.org/ref/import.html

</F>

[bruno modulix]

jean-marc wrote:

As an application programmer, I'm not well versed in the material
aspects of computing (memory, cpu, bus and all). My understanding of
imports in Python is such: the __main__ program is the center piece
which holds the programs reference: globals, functions, classes,
modules etc.
the '__main__' program is in fact just another Python module. What makes
it the 'main program' is the fact that you pass it to the Python
interpreter as a 'main program'.
The objects of this file (functions and classes) are
directly accessible;
from within this particular module only.
'import suchModule' s objects are attainable
through the *qualified name* (module.function); the 'from suchModule
import *' the objects are directly attainable.
Take care, this has other implications too.

(snip)
BUT, of all this I thought that if you import module1, then module2
(into __main__), objects from module1 would be available to objects of
module2 which came (into memory space) after module1 was loaded. This
does not seem to be the case,
This is not.
and module2 requires an 'import module1'
Right. And that's a Good Thing(tm).
statement in its own file to see this last module's objects. This is
not the recursive situation that was a pitfall Fredrik was evoking.
What am I missing here???

The term 'global' in Python is somewhat misleading. What it really means
is "global to the current module". Each module (and remember the 'main
program' is a module too) has it's own namespace.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[jean-marc]

Merci Bruno, ( and also to Fredrik )

So I think I understand correctly, if I say that:
each modulkes requires its own set of reference to whatever objects it
needs to speak. The interpreter wil see not to create extra copies of
the compiled code if many modules import the same modules but will make
them all point to the one already existing (in this program's
execution).

Practically, it means every module import whatever it needs - be
careful with recursive imports - keep things tidy by using the 'import
suchModule' (and use dotted name chains to reach whatever is needed).

Again thank you,

JM
PS Nice weather in Bordeaux ? I've been there once... (when I was young
(sigh))

[bruno modulix]

jean-marc wrote:

Merci Bruno, ( and also to Fredrik )

So I think I understand correctly, if I say that:
each modulkes requires its own set of reference to whatever objects it
needs to speak. The interpreter wil see not to create extra copies of
the compiled code if many modules import the same modules but will make
them all point to the one already existing (in this program's
execution).
Seems right.
Practically, it means every module import whatever it needs - be
careful with recursive imports - keep things tidy by using the 'import
suchModule' (and use dotted name chains to reach whatever is needed).
<hint>
There's a way to shortcut long.fully.dotted.Name without using the 'from
xxx import' syntax:

import long.fully.dotted
Name = long.fully.dotted.Name
</hint>

<OT> PS Nice weather in Bordeaux ?

Well... varying, as usual !-)
</OT>
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"