[Python-Dev] [Python-3000-checkins] r45617 - in python/branches/p3yk/Lib/plat-mac/lib-scriptpackages: CodeWarrior/CodeWarrior_suite.py CodeWarrior/__init__.py Explorer/__init__.py Finder/Containers_and_folders.py Finder/Files.py Finder/Finder_Bas

[Guido van Rossum]

On 4/21/06, Thomas Wouters <thomas at python.org> wrote:
>
> On 4/21/06, guido.van.rossum <python-3000-checkins at python.org> wrote:
> > The hardest part was fixing two mutual recursive imports;
> > somehow changing "import foo" into "from . import foo" where
> > foo and bar import each other AND both are imported from __init__.py
> caused things to break.  Bah.
>
> Hm, this is possibly a flaw in the explicit relative import mechanism.
> Normal circular imports work because a module object is stuffed into
> sys.modules before any code for the module is executed, so the next 'import'
> of that module just finds the half-loaded module object. I guess 'from .
> import name' really looks at the package contents, though, and there, the
> module isn't stored until it's done loading. I'm not sure why it raises a
> 'cannot import name' exception instead of recursing into a spiral of death,
> but I guess that's a good thing. :)

That's what I thought. But I believe I reproduced it in 2.4 as well.
I'm not 100% sure but I've got a feeling that the situation is
actually due to these imports happening *while __init__ is loading*.
When P is a package and M is a module, "from P import M" seems to
first check that sys.modules["P.M"] exists, but then it somehow asks
for P.M instead for sys.modules["P.M"]. At least that's how I cam up
with the fix (which sets P.M from inside M) and the fix made the
problem go away.

> Should this be fixed, or is it an esoteric enough case that I shouldn't
> bother?

I do think it ought to be fixed, and in 2.5 as well.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)