M.-A. Lemburg wrote:
Guido van Rossum wrote:
I'd much rather use absolute package names for anything that's not in the same directory as the current module.
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.
I can see your point (although I also believe that authors - Guido excepted - should come up with collision-free names, probably in a Java-ish scheme). But I strongly believe that import.c should be left alone, maybe even to die. There are too many people doing import hooks to make fiddling with its behavior safe. I'm also a strong proponent of Greg's imputil.py scheme, which makes it a breeze to do import hooks. And my experience disproves the notion that the import mechanism needs to be in C. If you don't believe me, try the ZlibArchive stuff (which is cross platform) from my Win32 installer stuff. You can pack the standard library into one 475K file, and get a perceptible performance boost. OTOH, I could see doing a framework of packages, in which case relative imports might be handy. This seems to work fine: def relimp(nm): rpth = string.split(nm, '/') tpth = string.split(__name__, '.')[:-1] for node in rpth: if node == '..': del tpth[-1] else: tpth.append(node) #print `tpth` return __import__(string.join(tpth, '.')) b = relimp('../packageA2.b')
As more and more packages appear, we run into this problem more and more often. Relative imports would greatly reduce the risk these collisions, because packages could be written self-contained meaning that they can reach their internal modules via relative paths only and don't have to know about the absolute paths by which they are reachable from other parts of the Python universe.
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'
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.
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.
-- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 111 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
_______________________________________________ Python-Dev maillist - Python-Dev@python.org http://www.python.org/mailman/listinfo/python-dev
- Gordon