[Python-Dev] New relative import issue
arigo at tunes.org
Sun Sep 24 00:15:11 CEST 2006
On Thu, Sep 21, 2006 at 07:22:04AM -0700, Guido van Rossum wrote:
> sys.path exists to stitch together the toplevel module/package
> namespace from diverse sources.
> Import hooks and sys.path hackery exist so that module/package sources
> don't have to be restricted to the filesystem (as well as to allow
> unbridled experimentation by those so inclined :-).
This doesn't match my experience, which is that sys.path hackery is
required in any project that is larger than one directory, but is not
itself a library. The basic assumption is that I don't want to put
whole applications in 'site-packages' or in my $PYTHONPATH; I would like
them to work in a self-contained, zero-installation way, much like they
do if they are built from several modules in a single directory.
For example, consider an application with the following structure:
This theoretical example shows main.py (the main entry point) at the
root of the package directories - it is the only place where it can be
if it needs to import the packages a and c. The module a.b can import
c, too (and this is not bad design - think about c as a package
regrouping utilities that make sense for the whole application). But
then the testing script test_b.py cannot import the whole application
any more. Imports of a or c will fail, and even a relative import of b
will crash when b tries to import c. The only way I can think of is to
insert the root directory in sys.path from within test_b.py, and then
use absolute imports.
(For example, to support this way of organizing applications, the 'py'
lib provides a call py.magic.autopath() that can be dropped at the start
of test_b.py. It hacks sys.path by guessing the "real" root according
to how many levels of __init__.py there are...)
More information about the Python-Dev