[Python-Dev] Relative Package Imports
Mon, 13 Sep 1999 20:21:08 +0200
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", [...]
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 ?
Y2000: 109 days left
Python Pages: http://www.lemburg.com/python/