Jean-Claude Wippler wrote:
"M.-A. Lemburg" wrote:
Gordon McMillan wrote:
Jim Fulton wrote: [deeply nested snippety snip]
This would motivate me to strangle the author of NiftyDB. He should say "This requires Marc-Andre's mx package", [...]
Yes.
Of course ;-) ... but that's not the point. Commercial products have to come with all batteries included, not just some of them. But you can't include everything known in the Python universe just to avoid conflicts when someone writes a cool plugin for your package.
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 it would probably affect other apps using the same package. Just think of what happens to Win9x if you constantly update the DLLs...
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. 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.
Currently, only the top-level installation of the mx package will work and this of course introduces other problems like version control, e.g. the NiftyDB product (relying on mx 1.9) may not support version 2.0 of mx which the sysadmin installed at top-level. There would be no way (apart from patching NiftyDB) to get back to a working setup.
Which points to a solution in a completely different direction: version numbers in package directories, like GNU and Tcl do, to name two.
A different topic -- an interesting one too :-) How does Java handle this problem ?
[...] have it enabled and available per default, so that writing self-contained packages becomes a standard in the Python world.
A noble goal.
And one which is only reachable by getting whatever mechanism is needed to make it work into the standard distribution -- not only a hook for relative imports but the real thing !
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.
True, but please remember that we are not talking about adding some esoteric module storage to the standard mechanism (the one reachable via the "import" statement). Relative import only adds a logical notion to imports that opens up new possibilities which are not easily available using other techniques. BTW, would you want to miss relative file name paths ? -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 109 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/