[Python-Dev] Relative Package Imports

[Jim Fulton]

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.