[Python-Dev] Re: Relative import
Guido van Rossum
guido at python.org
Thu Dec 18 10:59:00 EST 2003
> > 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).
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
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