[Python-Dev] Re: Christmas Wishlist
Guido van Rossum
guido at python.org
Mon Dec 15 14:54:46 EST 2003
> 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
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
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev