[Python-Dev] Re: Relative import

[Guido van Rossum]

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