[Python-Dev] Re: Christmas Wishlist
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_
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?
Nick Coghlan | Brisbane, Australia
Email: ncoghlan at email.com | Mobile: +61 409 573 268
More information about the Python-Dev