[Guido]
I'd much rather use absolute package names for anything that's not in the same directory as the current module.
[M.-A. Lemburg]
Of course, you could do everything with absolute names, but then the package author would dictate the complete absolute path which is not always desirable since it can cause name collisions such as DateTime in mxDateTime and Zope or Queue in mxQueue (to be released) and Mark's win32 stuff.
As more and more packages appear, we run into this problem more and more often.
I never understand package complaints. Maybe it's the imprecision of the language people use, or maybe because it's because people don't give fully fleshed-out examples. Whatever, in the end, I never have any idea what the complaint is, or in what way the solution is "solving" anything. In the above, "absolute" doesn't appear to mean "absolute" in any OS-sensible sense. So what does it really mean? Does it mean the same things to Guido and MAL? In MAL's hint of examples, I don't see any problem. If mxDateTime unpacks itself into a directory named DateTime, then *of course* it's going to collide with other packages that want to do likewise. Install it into mxDateTime instead, and take "absolute" to mean "any module that wants an mxDateTime service and does not itself live directly in mxDateTime/ must import the desired module via a path beginning 'mxDateTime.'", and everything looks straightforward to me (and that outcome makes me infer that this is thus probably what Guido has in mind too). Similarly for win32.Queue vs mxQueue.Queue vs the Queue in the std library (it *would* be good to have an explicit way to say "std library" -- "Lib." comes to mind).
I could then make all my packages self-contained and distribute them in two forms without having to change a single line for the added support:
1. under the new 'mx' package, e.g. mx.DateTime 2. for backward compatibility under 'DateTime'
Ah, so that's what this is about. I vote screw #2. Releasing it that way was a mistake. Better to live with the brief & finite pain of repairing it than complicating Python to cover up for it.
Another major advantage is that I could take any other self-contained package and install it under absolute paths of my choice, e.g. put Zope under org.zope.core, Python under org.python.core etc., without harming their functionality or having to dive deep into their import structures to fix them manually.
I view that not as an advantage but as harmful complication. Zope etc add great value to a Python installation, and when I write a killer app full of "import zope.this" and "import zope.that", I don't want the possibility that it's not going to work on my client's machine just because their sysadmin installed Zope into some silly site-specific path named after his soon-to-be ex-girlfriend <wink>. I don't want a way to work around him doing that, either: I don't want him to be able to screw me to begin with.
To further enhance this mechanism I would like to have an alias mechanism in import, pickle et al. so that changes in the package structures become manageable without user intervention: pickles are a major problem whenever import structures change because they store absolute module names.
This is a different issue, and may have merits of its own. WRT the relative import scheme, its advantage seems to lie in providing a way to partially recover from the damage the new scheme causes <0.5 wink>. As is, the package name used by a release is part of its published interface. You can't change it without causing pain, any more than you can make incompatible changes to public class methods or input-output behavior. In return, package clients are uniform, simple and portable, making life easiest for the people who know least. The burden is on package authors to choose names wisely, and that's where the burden should be. if-100-pkgs-all-want-their-own-queue-they-already-can-ly y'rs - tim