Bizarre import duplication.

Gabriel Genellina gagsl-py2 at yahoo.com.ar
Fri Mar 6 20:29:06 EST 2009


En Fri, 06 Mar 2009 22:05:53 -0200, Richard Thomas <chardster at gmail.com>  
escribió:

> Say I have a project like this:
>
>     ./run.py
>     ./package/__init__.py
>     ./package/mod1.py
>     ./package/subpackage/__init__.py
>     ./package/subpackage/mod2.py
>     ./package/subpackage/mod3.py
>
> And suppose that "." and "package" (or their absolute paths) are in
> sys.path.

That's a mistake. Never put redundant directories in sys.path. In this  
case, mod1 is reachable as "package.mod1" (from the "." entry in sys.path)  
and also as "mod1" (from the "package" entry). That must not happen -  
module names *must* be unique (here, "module name" means "sequence of  
package names plus the final file name", starting at some entry in  
sys.path)
Usually there is no need (and it's not even convenient) to put a package  
in sys.path -- the directory *containing* the package should be listed  
instead. In this case, it is ".".

> Now mod1.py and mod2.py both contain this:
>     from subpackage import mod3
>
> In this very particular case, the two references to mod3 are separate
> initialisations of mod3.py. This can't be the intended behaviour, its
> maybe a little contrived but I found myself want to set it up this way
> so it can't be outside possibility.

Using a relative import (and enabling absolute imports by default, by  
using: from __future__ import absolute_imports) is somewhat safer, but you  
can still confuse the complicated import machinery if you put redundant  
entries in sys.path

-- 
Gabriel Genellina




More information about the Python-list mailing list