[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