[Python-Dev] Relative Package Imports

Gordon McMillan gmcm@hypernet.com
Mon, 13 Sep 1999 10:35:16 -0400

[relative package imports]


> > I'll second Marc-Andre here.  

> > 

> > A significant headache occurs when you have a package

> > that has sub-packages.  Sub-packages need to be able to

> > reference other sub-packages within the same package without

> > knowing where the containing package is installed.


<color><param>0000,7F00,0000</param>> You never need to know where it is installed.  When I said absolute

> package name I meant package name (e.g. zope.foo.bar.subpack) not

> filename.  As Tim has argued, the ability to change the name of the

> toplevel here is a liability, not a feature.

</color>In between. I can see relative packages as *one* way of handling 
certain problems. Consider:



with both of these having alternate implementations of 
subpackages foo and bar. Then for (the current) foo.a to get to (the 
current) bar.b, using a relative import seems a natural.

This can, of course, be done in pure Python. So can doing things 
in zope.__init__.py that make the appropriate implementations of 
foo and bar appear to be zope.foo and zope.bar. On any criteria I 
can think of, this would be a superior solution. (*)

What I am against is further complicating the already over 
complicated built in import mechanism.

(*) such as a zope.__init__.py that looks like this:

import sys

if sys.platform[:3] == 'win':

  nm = __name__ + '.Win32'


  nm = __name__ + '.Unix'

new = __import__(nm)

sys.modules[__name__] = sys.modules[nm]<bold>

- Gordon