Jean-Claude Wippler wrote:
(snip)
The mx package installed in product dir won't be visible to outside scripts: it is self-contained and only works in the context of Zope.
But why shouldn't it be visible?
Because visibility has a cost. Making mx a top-level name means that someone else can't make it a top-level name. This is why packages are a good idea. If the need is local, the definition shouldn't be made global *just* to get around a limitation in spelling.
The only approach which will not self-destruct IMO, is to segment on source-of-origin. Your package in your namespace, Gordon's in his, and Jim's in yet another. Given that there is no ordering relationship, that means three areas next to each other.
It must be possible to package things together regardless of point of origin. Otherwise, you have a big obstical to reuse. BTW, I think that there is ample evidence that relative imports will not cause anything to self destruct.
If Jim takes M-A's package and modifies it, then that would be a reason to put M-A's-modified-by-Jim-package within Jim's area.
But Jim wants to use M-A's package as a black box. I don't want to hack all of his imports due to a packaging detail. (snip)
Now this may be a silly question, but what's the issue here? I'm used to writing things which sort of look like this: import myGoobledygook utils = myGoobledygook print utils.fun(123) Couldn't this be applied here as well: mxDT = aCoolImporter("Marc-Andre's latest date/time utilities") In other words: figure out a way to get at the proper modules, then use an alias in your own code to stay away from naming/access dependencies?
And if a parent wants to tell a submodule how to find it, can't it just set a variable at module level in that submodule, to reach it?
Aliases, bookmarks, symlinks, shortcuts, env vars, globals, registries, DNS or LDAP servers, FS mount points - it's all the same issue.
Yes, these are options, as are import hooks. While these are possible alternatives, they are far less attractive than simply making it possible to spell relative imports. Why? Well, for one, they require a lot of cooperation among packages that might be written by totally different authors. I might come up with a handy relative import function, but how do I get M-A to use it? Well, I'm sure I could get him to use it, but how about all of the other people whose packages I want to reuse. No problem, we'll come up with a standard mechansism, maybe even a standard library module. Of course, someone is bound to realize sooner or later that it's silly to have a standard relative import library module *and* a standard import statement and add the feature to standard import. :) 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.