[Python-Dev] Relative Package Imports

[James C. Ahlstrom]

Jim Fulton wrote:
> 
> Gordon McMillan wrote:
> >
> > Jim Fulton wrote:
> 
> > [Barry]
> > > > A
> > > > user would drop the kjParsing directory into Shared, and then
> > > > all the import kjParsing.kjParser statements would Just Work.
> >
> > To be a standalone application, you can use tricks that Jim
> > Ahlstrom pointed out, or tricks from my Installer. The major
> > point being that sys.path has nothing to do with the
> > PYTHONPATH environment variable. You now have an
> > installation where you can be assured of no collisions,
> > because you control it completely.

JimF, I am still trying to understand this.  Gordon, Barry and I
think a good solution is to put "Shared" on a private sys.path,
but you object to this and I don't understand.  Specifically
   zope/
   zope/Shared
   zope/Shared/mx/...
   zope/Shared/AnotherPackage/...
   zope/Shared/some_file.py
   zope/ZopePackage1/...
   zope/ZopePackage2/...
   zope/bin/python.exe
Suppose zope users must use the special binary zope/bin/python.exe.
Suppose further that this binary reliably sets its sys.path to
the directories it needs, namely zope, zope/Package*, zope/Shared.
Suppose further that all user's packages must go into zope/Shared
either as files or package directories and so are at the top
level as package imports have always assumed.

Then it seems that your zope app would absolutely work, and no
other Python installation could damage it by changing PYTHONPATH,
and that your zope installation would not damage any other Python
installation either.

Is the reason this doesn't work the posibility of name collisions
in zope/Shared?  I thought before that you were worried about name
collisions in another co-existing Python installation which may have
unknown packages installed, conflicting packages, or packages with
incompatible versions.

If so, you are trying to solve a problem more severe than I
thought.  I have always assumed packages would have unique
names and so a flat name space suffices.  In particular, trying
to design for conflicting names can not be supported by the
current python *.pyl library file design, and in general
would require a PYTHONPATH mechanism.  Such PYTHONPATH mechanism
would have to be "local" to packages.  That is, PYTHONPATH would
vary depending on the package doing the importing.

Are you sure this problem needs a solution right now?

Jim Ahlstrom