[Python-Dev] Relative Package Imports

[Guido van Rossum]

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 
(e.g. pythonware).

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