[Python-Dev] Re: Christmas Wishlist

[Nick Coghlan]

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