[Python-Dev] Relative Package Imports

[Jim Fulton]

"M.-A. Lemburg" wrote:
> 
> Tim Peters wrote:
> >
> > [Guido]
> > > I'd much rather use absolute package names for anything that's not in
> > > the same directory as the current module.
> >
> > [M.-A. Lemburg]
> > > Of course, you could do everything with absolute names, but then
> > > the package author would dictate the complete absolute path which
> > > is not always desirable since it can cause name collisions such
> > > as DateTime in mxDateTime and Zope or Queue in mxQueue (to be
> > > released) and Mark's win32 stuff.
> > >
> > > As more and more packages appear, we run into this problem more
> > > and more often.
> >
> > I never understand package complaints.  Maybe it's the imprecision of the
> > language people use, or maybe because it's because people don't give fully
> > fleshed-out examples.  Whatever, in the end, I never have any idea what the
> > complaint is, or in what way the solution is "solving" anything.
> 
> My original post contained an example package using relative
> imports. The example uses intra-package imports across subpackage
> levels which currently is only possible using absolute module
> names (see below for a definition).

I agree that this is a valid complaint about the current scheme.

> Note that I did not want to start a discussion about absolute vs.
> relative names (I believe everybody agrees that realtive file names
> are a Good Thing). The 'import __.module' thing is not new: ni.py
> had support for this and my patch simply adds it back to the
> implementation.

And, in fact, the current scheme does let you use relative paths
to go down.
 
(snip)
> > > I could then make all my packages self-contained and
> > > distribute them in two forms without having to change
> > > a single line for the added support:
> > >
> > > 1. under the new 'mx' package, e.g. mx.DateTime
> > > 2. for backward compatibility under 'DateTime'
> >
> > Ah, so that's what this is about.  I vote screw #2.  Releasing it that way
> > was a mistake.
> 
> Not until Zope went Open Source ;-) ...
> 
> >  Better to live with the brief & finite pain of repairing it
> > than complicating Python to cover up for it.
> 
> Screwing #2 is not possible unless I want all those already
> stored DateTime pickles to fail loading... ok, I could probably
> provide some kind of compatibility package which then redirects
> the import to mx.DateTime.

Regardless of how you spell the import, the pickles 
*must* reflect the absolute path.  Otherwise, pickleability
depends on where you unpickle.  If you rearrange packages, 
or rename modules, there is a pickling issue.  This is clearly
a problem in need of a better solution.
 
(snip)
> Zope is not a package AFAIK

Nope. If I had it to do over it would be.  It will be
eventually. (While Zope is not a package, it makes extensive 
use of packges. Zope has a total of about 350 modules and 
packages, of which about 44 are in the top-level namespace.)

> (and probably never will be due to the pickle complications),

The pickling issues are solvable in a number of ways, although
it is a bit painfull.  I considered fixing the package layout
in Zope 2, but I ran out of time. :)

> so 'import zope.this' won't work anyways
> unless you add a Zope wrapping package of your own -- and this will
> only work for Zope modules not relying on other Zope modules unless
> they use relative imports.

This is a good example. It should be possible to make Zope package-
portable but it isn't, at least not without writing import hooks, which
make my head hurt alot more than meta-classes. ;)
 
> > > To further enhance this mechanism I would like to have an
> > > alias mechanism in import, pickle et al. so that changes
> > > in the package structures become manageable without user
> > > intervention: pickles are a major problem whenever import
> > > structures change because they store absolute module names.
> >
> > This is a different issue, and may have merits of its own.  WRT the relative
> > import scheme, its advantage seems to lie in providing a way to partially
> > recover from the damage the new scheme causes <0.5 wink>.
> 
> I'm not proposing a new scheme... only a convenience for package
> authors.

I think that this is an important convenience that is probably not
appreciated until you write a complex package structure.
 
Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.