[Zope3-dev] Importing

[Martijn Faassen]

Guido van Rossum wrote:
[snip]
> I don't call it a non-issue, but I think you want something that is
> actually not good for you.  Consider the situation you sketch above,
> where you have a package A that you wrote and which needs a package B
> that you didn't wrote (or that's simply independent of it).  You can
> distribute them together in a tar file, with an install script that
> installs each in its proper place -- using distutils that's actually
> very easy.

So perhaps this is the solution to my issue. I didn't offer any particular
solutions, just the problem. Right now in Zope this isn't easy enough;
the standard way to install Products doesn't use distutils. It'd be
great if we used distutils and such for Zope3, however.

>  Or you can place them both in a parent package C that only
> exists as a convenient container for the two packages you distribute.
> The latter *seems* easier for you, and that's why you're asking me to
> make it easier for you (by allowing multi-level relative imports).
> But if you have several packages A1, A2, A3 that you distribute
> independently and that all need the same B, you end up not only
> distributing but also *installing* several copies of B, as subpackages
> of C1, C2, C3 (the container packages).  Each copy of B has its own
> global state, causing memory bloat in Python if A1...An are used
> together, and that state cannot be shared (suppose B maintains some
> kind of cache -- then C1.B, C2.B and C3.B each maintain their own
> cache).

Yes, and this should be avoided. So I agree that it'd be nicer if these
were installed separately from each other. So let's talk about resolving
the distribution issue.

Note that we're both using arguments from a maintenance on the longer
term point of view; I want to distribute it as a subpackage (but 
as modular as possible) because I know it may turn out to be independent
later on, and you say that if I do that I'll end up with a maintenance
problem later on.

Perhaps I should pull out NodePath out of ParsedXML sooner instead of
later.. The problem is that it is not a Product by itself, and 
right now there's only a well known way to distribute and install products
(in the Products directory), but installing other libraries (let's call 'm
services or utilities :) isn't arranged very well right now yet. Though
now that I think of it I think there's somekind of Shared directory.. 
Though I guess I can probably use the Products dir for it as well.

> If there's ever other software that needs to use B, it either needs to
> figure out in which container package B lives -- or distribute its own
> copy of B.
> 
> Sure, there are situations where version issues require you to
> distribute your own copy of B -- then I suggest that as a professional
> software developer and distributor you won't have a problem with doing
> a global substitute on the import statements to rename all references
> to B to C.B.
> 
> Note that Java doesn't have relative import at all.  There, you pick a
> unique package name and stick with it, and repeat it in every import.
> I'd like us to do the same for Python -- remembering explicit is
> better than implicit" in Tim's Zen of Python.  Distutils and
> site-packages have enough flexibility to support this.  For example,
> you can install all your packages in a subdirectory of site-packages
> that doesn't have an __init__.py, and use a .pth file to automatically
> add this directory to sys.path.

Okay, then let's leverage this existing infrastructure as well as we can
for Zope3 and I'll be happy. We need to specify where all the Zope3
things go (and how they are imported), from simple Python module and
packages to things like content objects, adapters, services, utilities,
and so on.

I'll start a wiki page on this.
 
Groeten,

Martijn