[py-dev] Import problems under py.test

[Ian Bicking]

holger krekel wrote:
> [Ian Bicking Wed, Nov 17, 2004 at 12:06:57PM -0600]
> 
>>I added a test to py.test (py/test/test/import_test) for this import 
>>problem.  Well, maybe the test belongs in py.path; anyway, it's there.
> 
> 
> yes, i saw it, thanks.  Note that (i think) the problem would also occur
> if you did the traditional "python test_myfile.py" which used unittest.py. 
> If you import relative from this file and then import (absolutely) from 
> the package then you would also get a different instance of the module. 

I just extended the test so you can run it as a script, and it works 
fine.  Since I mix relative and absolute imports frequently in my code 
(for better or worse), this is what I would expect.

You will get a problem with normal inputs when you are in a situation like:

/a/b/c.py

sys.path includes /a and /a/b

You "import c" somewhere, and "import b.c" somewhere else; this creates 
two modules that come from the same file.  But relative imports alone 
should not create another module.  Of course, I'm not sure if the 
relative import in this case will match the c module or the b.c... this 
is one of those places where "refuse to guess" would have been a better 
idea that the current behavior.

> However, i discussed the issue shortly with Armin this morning and 
> we may try to "guess" a more normal module path than a mangled str(Path object). 
> I.e. when we do: 
> 
>     py.test test_import.py 
> 
> we would traverse upwards from test_import.py as long as there is an 
> __init__.py.  The basename()s it so gathers would comprise the absolute 
> module path (which is used as a key for sys.modules).  
> 
> However, i am not completly sure about all this yet (my brain
> is exploding from the current pypy sprint in Vilnius :-). 

Importing is a pain in the ass, but that sounds like it should work. 
Alternately, could you try the normal import mechanism, see if it finds 
the same filename you are looking for, and if so procede with that?  I 
think imp has the functions to find a module without actually loading 
it.  Hrm... but no, you don't actually have a name to try.

Or, you could just look for common prefixes in sys.path, and if you find 
one traverse up making sure __init__.py's exist; most of the time they 
will.  This seems more optimistic.

Of course, I don't know if that will fix this test, because I modify 
sys.path after the module is loaded, so it would be loaded as an 
absolute path, and relative imports might still be funky.  Which makes 
me wonder how Python normally accomplishes this at all.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org