[Python-Dev] Relative Package Imports
Tue, 14 Sep 1999 16:24:06 +0200
James C. Ahlstrom wrote:
> "M.-A. Lemburg" wrote:
> > Still it doesn't avoid possible conflicts
> > due to being top-level, e.g. the user could install an extension
> > which relies on a specific top-level name already taken by the hosting
> > package, e.g. the host defines a DateTime package and the
> > extension comes with its own DateTime package. This is the current
> > situation with Zope and mxODBC (which needs mxDateTime).
> Yes, the name conflict at the global level is exactly the problem.
> And to repeat, I don't really mind if "__" is added to imports,
> although I don't like the spelling. But...
Doesn't look nice, but what other syntax would look better ? It will
have to use identifiers and thus is restricted to [a-zA-Z0-9_]+.
> Perhaps a better solution is a multiple global name space. Suppose
> there is a command line option (or other mechanism such as a special
> file in sys.executable) which specifies sys.path for the application.
> To be specific, suppose zope is installed in the "zopehome"
> directory and the zope package lives in zopehome/zope. And suppose
> zope needs mx, so it installs it in zopehome/mx. This really is an
> obvious structure, and anyone could see that replacing mx/* would
> upgrade the mx package. The sys.path would be zopehome plus perhaps
> some subdirectories of zopehome. Doesn't this solve the problem?
> Why not? And don't complain about wasted disk space. The smallest
> disk you can buy today is 4 gigs and costs $150.
This would solve the problem for Zope (but only after I have
restructured my packages to all go under the mx package -- which
is what started this thread; it wouldn't be needed using relative
But what about other installations or tools like mxCrypto
which plug into existing packages (Andrew's crypto package) ? Today
such plugins only work side-by-side, ie. you have to install one
part which sits in the plugin slot and one part which gets installed
somewhere in a top-level PYTHONPATH dir. The plugin slot part then
imports the Real Thing from outside the host package (this is how
mxCrypto integrates itself with AMK's lib).
> I find the PYTHONPATH mechanism totally unreliable for commercial
> programs anyway. It is a global object, and an installation of
> a second Python program can break the first one. I don't think
> there is any solution to this other than specify sys.path on a
> per-application basis. If this is false, what is the other
The solution I'm using (and Zope is too) is to wrap a
complete Python installation into the product, all setup to
do the right thing. It makes the archive a little heavier...
which is actually not so bad from a marketing POV. Bizarre,
but people seem to want all those megs.
Y2000: 108 days left
Python Pages: http://www.lemburg.com/python/