[Python-Dev] Re: Christmas Wishlist (original) (raw)

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 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/)

More information about the Python-Dev mailing list