[Python-Dev] Re: Christmas Wishlist

[Guido van Rossum]

> 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.

I know this line of reasoning fairly well.

You are taking 3rd party packages (or perhaps internally developed
packages) and copy them to a *different place in the package namespace
tree*.  Right?

But why do you have to give those packages a different full name?
That's the question that I've never seen answered adequately.

> 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.

I think that moving packages around in the package namespace is a bad
idea.  But maybe you can give me an answer to the question above to
convince me.

--Guido van Rossum (home page: http://www.python.org/~guido/)