[Python-Dev] Re: Relative import (original) (raw)

Paul Moore pf_moore at yahoo.co.uk
Thu Dec 18 09:40:30 EST 2003

Barry Warsaw <barry at python.org> writes:

On Tue, 2003-12-16 at 13:26, Guido van Rossum wrote:

A lot people have presented a good case for relative imports. Nobody has argued to keep the status quo (where imports are ambiguous about whether they are meant to be absolute or relative). So I suggest that in 2.4, we introduce the leading dot notation for relative import, while still allowing relative import without a leading dot. In 2.5 we can start warning about relative import without a leading dot (although that will undoubtedly get complaints from folks who have code that needs to work with 2.3 still). In 3.0 we can retire ambiguous import. I'll just note that where the current status quo trips /me/ up most is when I accidentally have a local module with the same name as a global module, and then I write an import statement expecting to get the standard library module, but end up getting the local module. That's why when I tend to think about this, I start wanting a way to spell "definitely give me the global one, no matter what". IOW, I feel like I want a way to bypass relative module lookups.

That issue I can understand. And I agree there should be a way to state it explicitly.

One of the issues here is that this area is a bit under-documented (I know, I should read the source, but I don't have the time right now).

At the moment, there are two cases:

  1. Import from sys.path. This is what is being called an "absolute" import, and is nice and easy to understand. The key issue is that there is no way to force this interpretation in the face of option (2) below.

  2. Import from "the package". This is the under-documented bit, but if I understand it correctly, it's basically that from within a module contained in a package, sys.path is conceptually extended to include the package's path (which by default contains the directory of the package, but which can be user-modified).

Now the big problem here is that behaviour (2) is useful. Simple "relative" imports of one module within a package from another module in the same package are common. Guido's (IMHO ugly) "dot" syntax handles that, by making users explicitly request option (2), and making the current import syntax only mean (1).

But none of the proposed solutions handle the path variable. I don't have any objection in principle to desupporting path (heck, it would have made thinking about PEP 302 easier, if nothing else) but (a) it would need a deprecation warning, and (b) Guido himself offered a use case in <http://www.python.org/doc/essays/packages.html>.

This definitely needs a PEP. If we're removing support for path, the implications need to be thought through (PEP 302, the pkgutil module, etc etc). If we're not, none of the proposals so far have covered how path gets supported in future.

A much simpler proposal, just providing an explicit way of saying "Import from sys.path only" may be OK without a PEP. But even then, I'd suspect we should have a PEP explaining why it has to be this simple.

Go on, Guido. We'll be gentle if you write a PEP, and we won't set c.l.p on you :-)

Paul.

This signature intentionally left blank

More information about the Python-Dev mailing list