[Python-Dev] Relative Package Imports

[Jim Fulton]

Gordon McMillan wrote:
> 
> [Jim Fulton]
> > Here's an example that I hope will be motivating:
> >
> > Suppose Marc-Andre has a package mx with subpackages DateTime
> > and stringtools.
> ...
> > Zope has a notion of products which are *self contained* packages that
> > are sub-packages of the Products package.  So, suppose someone wants
> > to write a NiftyDB product, which is a Zope product that provides
> > access to an external database.  Now the author of the NiftyDB product
> > wants to use the mx package.  The mx package is not a standard part of
> > Zope, or of Python, so they simpley include it in the NiftyDB product
> > directory.
> 
> This would motivate me to strangle the author of NiftyDB. He
> should say "This requires Marc-Andre's mx package", and put error
> handling on the import.

This is unacceptable. People should not have to hack a 
global namespace to get a local feature.

> Otherwise I might end up with a gazillion
> separate copies of the mx package installed on my system and no
> way to clean it up.

Or you might not.  In any case, the ability to have localized 
references should be there.

Actually, Zope does provide a place to share packages
that multiple products use. This involves putting
shared packages in a sub-package of the 'Shared'
package.  For example, Digital Creations
shared packages go in Shared.DC. 

Putting mx in Shared.ACME runs into the same
problem. Although the product author can:

  import Shared.ACME.mx.DateTime

the import of mx.stringtools in DateTime
will still fail.

Now, maybe ACME will hack mx to change the
internal imports:

  import Shared.ACME.mx.stringutils

but their hacks will get broken when 
we make Zope a package and Shared becomes
a sub-package of Zope.
 
> Your notion of "self contained packages" is flawed. Reducto ad
> adsurdum, it leads to downloading the OS with every app you
> install. (Crap, I hope I haven't given Sun any new ideas...).

I'm sorry, but relying on existing Python installations for
commercial applications is just not practical. In fact, Zope
binary distributions contain their own Python distributions 
because relying on preinstalled Python distributions is just
way too much of a support burden and a hassle for out customers.

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.