[Python-Dev] Relative Package Imports

[M.-A. Lemburg]

James C. Ahlstrom wrote:
> 
> First, I am not all that opposed to having a notion of ".."
> available in the import statement.  If we can write zope.dir1.mod1
> which is a relative import going down, maybe we can write
> ../dir2/mod2 or something spelled differently.  But I think
> there would still be problems.
> 
> We would be relying on all package authors to use ".."
> or "__" within their package.  But it is more natural to write
> zope.this.that or mx.this.that everywhere, and that is what
> people have in fact done.  Probably there would be bugs and
> at least annoyance.

Think of it as an opportunity: it makes intra-package imports
very simple without hard-wiring paths to submodules
into the package.

In the end, having written a self-contained package is a "feature"
of that package. Other authors can then say: ok, I can
plugin your package if it's self-contained.

--

I have a feeling that this discussion is loosing its grip
on reality a bit. Jim and I are not argueing to change
Python's face, internal structure or look&feel. The '__' thing
doesn't harm anyone, doesn't break any functionality or
code. It is even now already possible using import hooks and
has been implemented before in ni.py using just that technology.

All that we are talking about is reviving relative imports
so that its usage is possible *without* adding yet another
hook. This is not about the pros and cons of deeply nested
packages and neither about advantages of shallow structures.
Its only about adding semantics to the string '__' used
in import statements. Nothing more. People are not forced
to use it. Besides, if used it will be a package internal
technique and not be visible to users of that package.

Now why would anyone want to make life harder for package
authors ? Give the people something to play with so that
they have more fun at what their doing for the benefit
of the community !

--
 
> And it seems unfortunate to need this feature.  A proper
> package scheme should really isolate package internals from
> the outside world, and if this isn't happening we need a new scheme.
> 
> I also don't think there is any escape from needing standard
> package names, at least the head name "zope" for example.
> 
> Of course all this currently works if (in Jim's example) both
> "zope" and "mx" are top-level names.  Then the ".." is not
> necessary.  But, as Jim points out:
> 
> >> 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.
> 
> The global shared nature of PYTHONPATH and its name space makes
> it difficult to guarantee that all required packages are going
> to be present in a complicated installation like zope.  And if
> anyone else installs another Python package, it can easily break
> the first installation.
> 
> One solution is for an application to establish its own
> PYTHONPATH which can not be altered.  If this points to "zopedir"
> then the installer can freely install mx to the directory
> zopedir/mx and be confident that another mx installation
> is not damaged, nor used.
> 
> The logical extension is to place each package into its own
> file using a scheme like Gordon McMillan is using.  If the
> package contents is obtained by seeking from the END of the
> file, then multiple package files can be concattenated with
>   cat package1 package2 zope mx >> bigpackage
> and a large installation like zope can be shipped with its
> own "bigpackage" library which is essentially a normal
> PYTHONPATH archive with everything above the head directory
> names thrown away.  The Python library is included under
> "Lib" just as it is now.  The bigpackage library implies
> its own PYTHONPATH of "Lib;."  If the Python library files are
> placed in the root, the implied PYTHONPATH is ".".

This is a possibility and in fact I'm using such a setup in my
current application. Still it doesn't avoid possible conflicts
due to being top-level, e.g. the user could install an extension
which relies on a specific top-level name already taken by the hosting
package, e.g. the host defines a DateTime package and the
extension comes with its own DateTime package. This is the current
situation with Zope and mxODBC (which needs mxDateTime).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                   108 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/