Guido van Rossum wrote:
[MAL]
I've spent the last two hours trying to get relative package imports to work because I need them for my extension packages which will soon all move under a new top-level package name to overcome the conflicts with PIL and Zope. [GvR] I'd much rather use absolute package names for anything that's not in the same directory as the current module. [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.
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.
I think Jim meant the absolute package name just like you and I did. I don't really understand why you and Tim oppose to relative imports... Tim's argument about sysadmins installing packages under fantasy names isn't really all that realistic, IMHO, even though it would work. The ability to host a subpackage inside another package is a very attractive feature for large package based applications: you don't have to edit a single line in the subpackage's source code and can install/update the subpackage without harming its functionality within the system. BTW: The patch I posted does not add a circular reference to the modules as the old ni.py implementation (sometimes) did. Since the __ handling is done dynamically and on import only there is no need to add a module attribute __ pointing to the parent module. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 109 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/