[Python-Dev] Relative Package Imports

[James C. Ahlstrom]

"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...

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.

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?

Jim Ahlstrom