On 2 Jun 2002 at 9:25, Guido van Rossum wrote: [Matthias Urlichs]

...

The problem is that importing with from consists of two steps: - load the module - add the imported names to the local namespace

Good explanation! This means it's an unavoidable problem.

Um, different problem. What Matthias explains is unavoidable. But in David's case, the containing namespace (the package) is not empty when module2 wants module1. In fact, I believe that sys.modules['package.module1'] is there (though *it* is empty). My guess is that import is looking for module1 as an attribute of package, and that that binding hasn't taken place yet. If I use iu instead of the builtin import, it works. -- Gordon http://www.mcmillan-inc.com/

Hi, David Goodger:

Perhaps I'm just dense, or perhaps it's because of my choice of names in my example, but I don't understand the explanation. Could you be more specific, perhaps with a concrete example?

foo.py: from bar import one bar.py: from foo import two main.py: import foo So what happens is, more or less: main imports foo Empty globals for foo are created foo is compiled foo loads bar Empty globals for bar are created bar is compiled bar loads foo (which is a no-op since there already is a module named foo) bar.two = foo.two ... which fails, because the compiler isn't done with foo yet and the global symbol dict for foo is still empty.

eliminate my confusion. I suspect it's a good explanation for those that already understand what's going on behind the scenes.

_If_ you can change foo.py so that it reads: two = 2 from bar import one i.e., initialize the exports first and load afterwards, the test would work. However, the following will NOT work: two = None from bar import one two = do_something(with(bar.one)) for (hopefully) obvious reasons. -- Matthias Urlichs | noris network AG | http://smurf.noris.de/

The note in section 6.12 ("The import statement") of the Language Reference, "XXX Can't be bothered to spell this out right now", has always bothered me. I will endeavour to flesh it out for release 2.3. Perhaps Guido's package support essay (http://www.python.org/doc/essays/packages.html), edited, should form a new section or appendix. Ideas anyone?

The information should be worked into the language reference IMO. I'm not sure if an appendix is appropriate or if this could be part of the documentation for the import statement. Thanks for helping out!!! --Guido van Rossum (home page: http://www.python.org/~guido/)

Hi, Gisle Aas:

Perl doesn't add references to names. It imports direct reference as well.

What I meant to say was: Perl shares the actual symbol table slot when you import something; so a later reassignment to the variable in question will affect every module. Python doesn't have that additional indirection.

In Perl this works because we at import time know if we are importing a variable (and what kind) or a function, and later assignments to variables or redefinitions of functions mutate the object in-place.

... which is essentially a different way to state the same thing. ;-) -- Matthias Urlichs | noris network AG | http://smurf.noris.de/

Hi, Gisle Aas:

...

What I meant to say was: Perl shares the actual symbol table slot when you import something;

Wrong. If you do:

package Bar; use Foo qw(foo);

Then you end up with \&Bar::foo and \&Foo:foo pointing to the same function object, but the symbol table slots are independent.

Right, actually; we're just miscommunicating. Let's state it differently: the situation is more like "use Foo qw($foo)" (you can't assign to &Foo::foo). After the "use", \$Bar::foo and \$Foo:foo point to the same scalar variable, thus $Foo::foo and $Bar::foo are the same variable and no longer independent (unless a different scalar or glob reference is stored in to *Foo::foo, but that's too much magic for a FAQ entry). In Python, Bar.foo gets set to the contents of Foo.foo when the import statement is processed, but the two variables are otherwise independent. -- Matthias Urlichs | noris network AG | http://smurf.noris.de/