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