[Zope3-dev] Importing

[Chris Withers]

Guido van Rossum wrote:
> 
> 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.  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).

Yup, I'd agree with this...

> 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.

Not entirely convinced....

> 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.

Hmmm.... for me it feels mroe abotu end users slotting components (packages in
this case) together in a meaningful but different way that the package author
knew about or should need to care about...

> 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.

Yeah, but then you end up with a lot of conflicting things named 'Image' and
'utils', etc...

> better than implicit" in Tim's Zen of Python.  Distutils and
> site-packages have enough flexibility to support this.  

Where can I find a good introduction to distutils?

cheers,

Chris