[Python-Dev] Relative Package Imports

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> 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).

I'm wasn't planning to write my own hook until now. I need this
feature to be able to organize my package internal stuff swiftly
and easily, plus to be able to possibly put it under new top-level
packages. Obviously I seem to be more or less alone with this need, so
I'll stop argueing for inclusion of "something like relative imports"
in the distribution.
 
> 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).

(b) is (if at all) a problem only to be taken into account by
the author of package X. He may or may not use rel. imports.
A 12-year old probably won't (but then: you never know ;).

BTW, what is this CP4E thing you're talking about. If it's an
syntax aware editor, I have a friend who is really interested
in these things... could you send me an URL that I can send him ?
 
> 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! 

Oh well... I guess they'll have to use 'mex' if they decide to go
the reverse domain way ;-)

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

True, perhaps we should lighten this requirement a little when we
recode the import mechanism in Python ? E.g. if a local import
fails continue the search with the fully qualified name and only
if that fails, restart using the local name. This would need some
kind of fastpath cache to make the search reasonably fast though.
 
> 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.

Wouldn't it suffice to just put them into one package, e.g.
'python.' ?

BTW, as Tim argued: the breakage an easily be leveraged by using
a smart editor... ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                   106 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/