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/