[Python-Dev] Relative Package Imports

Tim Peters tim_one@email.msn.com
Wed, 15 Sep 1999 02:42:02 -0400

Don't tell, but this is getting repetitive.  One more batch of repeats from
me, and I'm done:

+ The notion that Python packages aren't self-contained now is wrong:  a
package module can import other modules in the package without
qualification.  This is good design.

+ Where self-containment breaks down is in going across *sub*-packages.  I
was surprised Guido pretended to cater to them, since Python (wisely, IMO)
stayed away from sub-modules from the start.  Hierarchy is a great tool for
managing complexity, but it also introduces complexity of its own.  And when
a flat package space suffices, hierarchy introduces artificial

+ I agree with Gordon that, if anything, the default "import" behavior is
already too complicated.  By the time you wade thru PYTHONPATH, and
PYTHONSTARTUP, and .pth files, and people mucking with sys.path, and site
config files, and symlinks under Unix, and packages mucking with their own
__path__ attributes, running Python with -v is the only hope of figuring out
why nothing ever works <0.6 wink>.

+ All this dynamicism is in support of a concept that's actually static:
the structure of an installation.  As Barry laments, you can't always know
the structure in advance of installation, but the solution is (I believe)
along the lines he suggests:  invent a way to register/query the structure
once & for all after it is known.

+ JimF and MAL's shared notion that they're the only ones making significant
use of packages is myopic.  Dragon also uses packages, and heavily, although
products using them have not been announced and I can't talk about them yet.
Anything I'm within 10 miles of doesn't use *any* import hooks, or play any
other tricks on the system.  Instead I urge people to write their imports as
explicitly, long-windedly and straightforwardly as possible (with binding to
a convenient local alias name on the following line).  Do we embed
sub-packages?  Sure.  Do modules move around in the hierarchy over time?  Of
course.  So how do we deal with this supposed nightmare?  Because all
imports are relentlessly straightforward (even intra-package imports are
fully qualified), and none are hiding in dynamic functions, we get into
Emacs and do a global search-and-replace.  Takes 30 seconds, and the new
structure is plain as day to everyone reading the code.

low-tech-it's-not-just-for-breakfast-anymore<wink>-ly y'rs  - tim