[Python-Dev] Relative Package Imports
Sat, 11 Sep 1999 22:41:44 -0400
M.-A. Lemburg wrote:
> Guido van Rossum wrote:
> > I'd much rather use absolute package names for anything that's not
> > in the same directory as the current module.
> 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.
I can see your point (although I also believe that authors - Guido
excepted - should come up with collision-free names, probably in a
But I strongly believe that import.c should be left alone, maybe
even to die. There are too many people doing import hooks to
make fiddling with its behavior safe.
I'm also a strong proponent of Greg's imputil.py scheme, which
makes it a breeze to do import hooks. And my experience
disproves the notion that the import mechanism needs to be in C. If
you don't believe me, try the ZlibArchive stuff (which is cross
platform) from my Win32 installer stuff. You can pack the standard
library into one 475K file, and get a perceptible performance boost.
OTOH, I could see doing a framework of packages, in which case
relative imports might be handy. This seems to work fine:
rpth = string.split(nm, '/')
tpth = string.split(__name__, '.')[:-1]
for node in rpth:
if node == '..':
return __import__(string.join(tpth, '.'))
b = relimp('../packageA2.b')
> As more and more packages appear, we run into this problem more
> and more often. Relative imports would greatly reduce the
> risk these collisions, because packages could be written
> self-contained meaning that they can reach their internal
> modules via relative paths only and don't have to know about
> the absolute paths by which they are reachable from other parts
> of the Python universe.
> 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'
> Another major advantage is that I could take any other
> self-contained package and install it under absolute paths
> of my choice, e.g. put Zope under org.zope.core, Python under
> org.python.core etc., without harming their functionality
> or having to dive deep into their import structures to fix
> them manually.
> 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.
> Marc-Andre Lemburg
> Y2000: 111 days left Business:
> http://www.lemburg.com/ Python Pages:
> Python-Dev maillist - Python-Dev@python.org