[Python-Dev] RFC: Including PIL in 1.6

Paul Prescod paul@prescod.net
Tue, 20 Jun 2000 13:42:21 -0500


"Andrew M. Kuchling" wrote:
> 
> ...
> 
> I just compiled XEmacs 21.1.10 on a new Linux machine; you compile the
> binary, and install two packages of Elisp code (EFS and xemacs-base).
> Then you run xemacs, do Options > Manage Packages > List and Install,
> and you get a nice list containing GNUS, W3, programming language
> modes, etc.  Pick the ones you want, it adds the ones needed by the
> ones you selected, and it fetches and installs them.  Easy!  Now
> imagine doing the same thing with Python modules.  Of course, we'd
> have to design that feature first...

Let me repeat that I don't think that the main issue is whether it lives
in this tarfile versus that tarfile. It's 

 a) about agreeing to keep everything comptible.
 b) about being able to depend on the thing being there when you write a
module.

*In theory* Red Hat linux could be a kernel, a shell and the RPM engine.
In practice, people like to be able to say: "if you have Red Hat version
X then such and such will work because it comes with a functional
package Y."

Distutils is extremely important for vertical modules but if we start to
use it as an excuse for leaving out core modules then I have to go with
ESR and say: "where do we stop?" 

Unicode on demand? re on demand? pickle on demand?

I think that the more relevant criteria are the ones we have always
used:

 * how big is it
 * how easy is it to maintain
 * how integrated is it with everything else
 * how well-thought-out is it
 * and most important: how many people want it?

I think that PIL is not yet a clear home run.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
"Music is the stuff between the notes." - Claude Debussy