[Python-Dev] Relative import

Greg Ewing greg at cosc.canterbury.ac.nz
Tue Dec 16 19:22:49 EST 2003


Guido:

> 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

If I understand correctly, the rule you're working towards is that if
the path starts with a dot, it's relative, otherwise it's absolute. Is
that correct?

I'm not sure whether eliminating the "ambiguous" category of
module references is the best idea. There are situations in which
it's actually what you want.

Suppose there are two top-level modules A and B, and A imports B
using a bare name. Then someone decides to put A into a package.
The reference to B still works. Then they decide to put B into
the same package as well. The reference to B still works.

But if only unambiguously absolute or relative references are
possible, there is no way for A to refer to B that works in all
these combinations.

So I think we really want *three* kinds of module reference:

   A: Explicitly absolute
   B: Explicitly relative to the current module
   C: Searched for upwards in the package hierarchy from the current
      module

(Note that C is a generalisation of the current "ambiguous"
references which only look in two places.)

Suggested syntaxes for these:

  A:   a.b.c.          Path ends with a dot

  B:   .a.b.c          Path begins with a dot

  C:   a               Path neither begins nor ends with a dot
       a.b.c

Note that ALL current module references would be type C according
to this. Yes, this is a semantic change, but one that I believe
would be for the best in the long run, and don't think would cause
a lot of upheaval.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+



More information about the Python-Dev mailing list