[Python-Dev] Relative Package Imports

[Jim Fulton]

Tim Peters wrote:
> 
(snip)
> As is, the package name used by a release is part of its published
> interface.  You can't change it without causing pain, any more than you can
> make incompatible changes to public class methods or input-output behavior.
> In return, package clients are uniform, simple and portable, making life
> easiest for the people who know least.  The burden is on package authors to
> choose names wisely, and that's where the burden should be.

Not all packages are part of the external interface. In fact, 
all Zope names are essentially internal, since Zope is an application.
The issue is not so much access to access from outside as it is access
between packages within Zope.

Further, the current support for relative imports allows a package
to be moved into another package without breaking the pulic interface wrt 
the containing package.

Here's an example that I hope will be motivating:

Suppose Marc-Andre has a package mx with subpackages DateTime
and stringtools.  If mx was installed in the Python path
then a module in the mx.DateTime package could get at stringtools
like:

  import mx.stringtools

So far, so good.

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.  Becase relative imports are
allowed in the current import scheme, they can use mx as usual.
A NiftyDB module can import DateTime as follows:

  import mx.DateTime

So even though mx is istalled as a sub-package, the public
interface is unchanged, at least wrt the containing package.

Unfortunately, the internal import of stringtools in the DateTime
package:

  import mx.stringtools

will fail, because mx is no longer a top-level module.
 
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.