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

Nick Coghlan ncoghlan at iinet.net.au
Tue Dec 16 05:32:16 EST 2003

Guido van Rossum wrote:

I don't understand the desire to totally prevent relative imports. 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.

If absolute imports were to be the only type allowed, then it would seem that the only possible location for naming conflicts is in the first element.

So if I wanted to use two different third party modules, both of which have unfortunately chosen the same name for the top-level package, the only way to let them co-exist is to redo all of the imports in one or the other of them.

Whereas, if relative pathing is possible, I believe that all I have to do is push them one level down in the package heirarchy (using distinct names that I invent), and neither of them ever even knows about the other's existence. I can get at both of them unambiguously, by using my new top=level names, and neither package even knows that it is no longer starting at the top of the import heirarchy.

Or is there some other solution being proposed to this problem, and I just haven't understood it?

Cheers, Nick.

-- Nick Coghlan | Brisbane, Australia Email: ncoghlan at email.com | Mobile: +61 409 573 268

More information about the Python-Dev mailing list