[Python-Dev] Relative Package Imports

[M.-A. Lemburg]

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
imports).

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
> solution?

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.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                   108 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/