[Python-Dev] Re: Christmas Wishlist

[Ken Manheimer]

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