[Python-Dev] Re: Relative import

[Paul Moore]

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