"M.-A. Lemburg" wrote:
Tim Peters wrote:
[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.
My original post contained an example package using relative imports. The example uses intra-package imports across subpackage levels which currently is only possible using absolute module names (see below for a definition).
I agree that this is a valid complaint about the current scheme.
Note that I did not want to start a discussion about absolute vs. relative names (I believe everybody agrees that realtive file names are a Good Thing). The 'import __.module' thing is not new: ni.py had support for this and my patch simply adds it back to the implementation.
And, in fact, the current scheme does let you use relative paths to go down. (snip)
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.
Not until Zope went Open Source ;-) ...
Better to live with the brief & finite pain of repairing it than complicating Python to cover up for it.
Screwing #2 is not possible unless I want all those already stored DateTime pickles to fail loading... ok, I could probably provide some kind of compatibility package which then redirects the import to mx.DateTime.
Regardless of how you spell the import, the pickles *must* reflect the absolute path. Otherwise, pickleability depends on where you unpickle. If you rearrange packages, or rename modules, there is a pickling issue. This is clearly a problem in need of a better solution. (snip)
Zope is not a package AFAIK
Nope. If I had it to do over it would be. It will be eventually. (While Zope is not a package, it makes extensive use of packges. Zope has a total of about 350 modules and packages, of which about 44 are in the top-level namespace.)
(and probably never will be due to the pickle complications),
The pickling issues are solvable in a number of ways, although it is a bit painfull. I considered fixing the package layout in Zope 2, but I ran out of time. :)
so 'import zope.this' won't work anyways unless you add a Zope wrapping package of your own -- and this will only work for Zope modules not relying on other Zope modules unless they use relative imports.
This is a good example. It should be possible to make Zope package- portable but it isn't, at least not without writing import hooks, which make my head hurt alot more than meta-classes. ;)
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>.
I'm not proposing a new scheme... only a convenience for package authors.
I think that this is an important convenience that is probably not appreciated until you write a complex package structure. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.