[Python-Dev] Relative Package Imports
Guido van Rossum
Wed, 15 Sep 1999 23:32:18 -0400
I don't like the pressure to allow relative imports and I don't like
the solutions that those who insist on having it propose (they are all
writing their own import hooks).
The reasoning seems to be something like this:
(a) If my package needs non-standard package X, I can't require that X
be installed as a top-level package, because there might be another
unrelated package also called X; therefore I need to install a copy of
package X as a subpackage of my own package.
(b) Because any non-standard package X now may be installed at the
toplevel or as a subpackage of some other package, X must use relative
imports exclusively to access subparts of itself.
I find (b) unacceptable for a number of reasons, that have all been
explained by others: duplicate installs (and hence possible imports)
of the same package as a subpackage of various other packages, the
requirement to be religious in the use of relative imports, the
ugliness of the __ notation (I do *not* look forward to explaining
that to 12-year-olds in the context of CP4E).
I think that the fear expressed in (a) is an overreaction to some
recent actual top-level name clashes. This was a real pain, but
notice that it happened because several popular module collections
weren't packagized at all!
In the Java world, the right solution exist: a better top-level naming
scheme. I forget what the exact rules are, but I seem to recall that
Java has something of the same relative import rules af Python
currently has: you can import a class from the same leaf package by
its simple name, or you can import a class by its full name. As Tim
explains, the occasional renames are easily handled with a global
substitute in a smart editor.
I don't want to do the same thing as Java and require everybody to use
their reversed domain name as their package name. Of course you are
free to do so: there are currently no toplevel modules or packages
that I know of named org, com, edu, gov, mil or net. Two letter
domains are all free except for re=Reunion (and ni=Nicaragua, but ni
is expired). Oops, mx=Mexico! Well, Python package semantics are
slightly different than Java semantics in that shared ownership of a
subpackage of (e.g. :-) mx is harder in Python than in Java (Python
requires that they are installed in the same directory; Java doesn't).
In any case the proper thing to do is to pick a good unique toplevel
name. Aaron Watters did a great job with kj (not a country code
either!); Marc Andre also has the right spirit with mx. CNRI will
probably use cnri as the toplevel package name for CNRI-developed
packages that aren't distributed together with Python.
If there are still worries about name choices, I volunteer to run a
toplevel name registry. This has worked well e.g. for Apple where
application developers had to pick a unique 4-letter code; certainly
better than the Windows world where conflicting 3-letter extension
definitions are common. In the Python world, I would recommend longer
toplevel names, so it's more likely that you can use your company name
Note that I still resist the urge to start renaming all the existing
standard modules -- too much breakage. This will happen in 2.0.
--Guido van Rossum (home page: http://www.python.org/~guido/)