[Python-Dev] Re: Christmas Wishlist (original) (raw)

Ken Manheimer klm at zope.com
Mon Dec 15 14:34:33 EST 2003

On Mon, 15 Dec 2003, Guido van Rossum wrote:

> It would be quite useful in avoiding growing module-naming problems, > where you have to be careful about shadowing a global module with > one in your package.

I don't see the problem, or I misuderstand what "it" refers to; it seems you have this backwards if it refers to relative imports. Say my package P defines a submodule sys. If we require absolute imports, there is no ambiguity: the submodule sys must be imported as P.sys while the standard sys module can be imported as simply sys.

I guess i think there is a case to be made for relative imports, and it becomes apparent as an enterprise grows.

Increasingly at Zope corp we are mixing and matching packages to deliver applications to a customer. This is very encouraging, because it means we are actually getting reuse out of the packages.

Currently, we can just plop the things in place, and use them. Without relative imports, we would have to be editing the imports in the packages in each place we use it. This would increase the burden of using the packages and even more of feeding back actual fixes - which we then have to distinguish from what i would see as gratuitous changes to edit import names.

If you would grant there's use to avoiding those edits, and so there's use to having relative imports, then you might see a reason to solve the problems where the names in a package conflict with those along the load path. Otherwise, if there's only absolute imports, there's no ambiguity to resolve. I'd say there's a legitimate need for relative imports, and we need some explicit gesture to disambiguate between a relative and absolute import, one way or the other.

Ken

More information about the Python-Dev mailing list