[Python-Dev] question/comment about documentation of relative imports

Antoine Pitrou solipsis at pitrou.net
Tue Oct 5 19:45:09 CEST 2010

Le mardi 05 octobre 2010 à 13:28 -0400, Darren Dale a écrit :
> >>
> >> As the OP pointed out, for code that may be *included* in other projects
> >> there is no other choice. This is often useful for packages shared
> >> between one or two projects that nonetheless don't warrant separate
> >> distribution.
> >
> > You can put several packages in a single distribution.
> Thats not the point though. Due to compatibility issues, maybe I don't
> want to expose the code at the top level. Maybe the foo package is
> distributed elsewhere as a top-level package, but I need to use an
> older version due to compatibility problems. I certainly don't want to
> risk overwriting a pre-existing installation of foo with my required
> version of foo. This is not a hypothetical, we once had exactly this
> problem when we distributed an old version of enthought.traits with
> matplotlib

That use case requires that the third-party package, not your package,
use relative imports. I don't think you can require other projects to
follow your coding style recommendations (unless of course you maintain

And of course you can simply set sys.path to point to your private
copies of vendor libraries. Or you can manually import them using the
"imp" module.

> (even though we checked for pre-existing installations,
> crufty build/ directories containing the out-of-date traits package
> were overwriting existing installations).

I'm not sure I understand the issue. If there's a distutils bug you can
report it on http://bugs.python.org.

In the end, I think Python offers enough packaging and module
locating/loading options that relative imports shouldn't be used just
for "distribution purposes".



More information about the Python-Dev mailing list