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

Guido van Rossum guido at python.org
Thu Dec 18 10:59:00 EST 2003

[Barry]

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

[Paul Moore]

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.

Right.

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

That's not a very useful way to think about it; when the module is found on path something very different happens than when it is found on sys.path. The difference is noticeable if you ask the imported module for its name. If you the import was satisfied from path, then name will include the package name. If it was satisfied from sys.path, it won't. And name is related to module identity: all modules are stored in sys.modules using their name as the key, so multiple imports of a module with the same name end up referring to the same module (and only the first import causes the module's code to be executed).

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

Actually, what you consider useful is considered harmless by others. Many large packages, including Zope, have adopted a rule of always using absolute imports, to clarify what kind of import is being used.

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

path has no bearing on the proposals, it is used for relative imports. I think your confusing about how the current import works caused you to think it is relevant.

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.

We're not, but they have (by not mentioning it); but I agree that a PEP is needed.

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.

This was where this thread started: someone proposed a way of spelling "import from sys.path only". My big problem with that is that most imports are intended to be satisfied by sys.path only, so this spelling should be the default, meaning the current spelling.

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

Alas, I have no time.

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

More information about the Python-Dev mailing list