[Python-Dev] Relative Package Imports

Gordon McMillan gmcm@hypernet.com
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 
Java-ish scheme).

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:

def relimp(nm):
  rpth = string.split(nm, '/')
  tpth = string.split(__name__, '.')[:-1]
  for node in rpth:
    if node == '..':
      del tpth[-1]
    else:
      tpth.append(node)
    #print `tpth`
  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:     
>                      http://www.lemburg.com/python/
> 
> 
> 
> _______________________________________________
> Python-Dev maillist  -  Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev



- Gordon