[Python-Dev] Relative Package Imports
Gordon McMillan
gmcm@hypernet.com
Mon, 13 Sep 1999 10:35:16 -0400
[relative package imports]
<color><param>0000,7F00,0000</param>[JimF]
> > 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>[GvR]
<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:
zope.Win32
zope.Unix
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'
else:
nm = __name__ + '.Unix'
new = __import__(nm)
sys.modules[__name__] = sys.modules[nm]<bold>
<nofill>
- Gordon