[Python-Dev] Adding library modules to the core

[Greg Ward]

[cc'd to python-dev, since I think this belongs out in the open: Moshe,
if you really meant to keep this private, go ahead and slap my wrist]

On 10 August 2000, Moshe Zadka said:
> Greg, this sounds very close to PEP-206. Please let me know if you see
> any useful collaboration with it.

They're definitely related, and I think we're trying to address the same
problem -- but in a different way.

If I read the PEP (http://python.sourceforge.net/peps/pep-0206.html)
correctly, you want to fatten the standard Python distribution
considerably, first by adding lots of third-party C libraries to it, and
second by adding lots of third-party Python libraries ("module
distributions") to it.  This has the advantage of making all these
goodies immediately available in a typical Python installation.  But it
has a couple of serious disadvantages:
  * makes Python even harder to build and install; why should I have
    to build half a dozen major C libraries just to get a basic
    Python installation working?
  * all these libraries are redundant on modern free Unices -- at
    least the Linux distributions that I have experience with all
    include zlib, Tcl/Tk, libjpeg, and ncurses out of the box.
    Including copies of them with throws out one of the advantages
    of having all these installed as shared libraries, namely that
    there only has to be one copy of each in memory.
  * tell me again: what was the point of the Distutils if we just
    throw "everything useful" into the standard distribution?

Anyways, my idea -- the Python Advanced Library -- is to make all of
these goodies available as a single download, *separate* from Python
itself.  It could well be at the the Advanced Library would be larger
than the Python distribution.  (Especially if Tcl/Tk migrates from the
standard Windows installer to the Advanced Library.)

Advantages:
  * keeps the standard distribution relatively small and focussed;
    IMHO the "big framework" libraries (PIL, NumPy, etc.) don't
    belong in the standard library.  (I think there could someday
    be a strong case for moving Tkinter out of the standard library
    if the Advanced Library really takes off.)
  * relieves licensing problems in the Python distribution; if something
    can't be included with Python for licence reasons, then put
    it in the Advanced Library
  * can have variations on the PAL for different platforms.  Eg. could
    have an RPM or Debian package that just requires libjpeg,
    libncurses, libtcl, libtk etc. for the various Linuces, and an
    enormous installer with separate of absolutely everything for
    Windows
  * excellent test case for the Distutils ;-)
  * great acronym: the Python Advanced Library is your PAL.

Sounds worth a PEP to me; I think it should be distinct from (and in
competition with!) PEP 206.

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange / CNRI                           voice: +1-703-262-5376
Reston, Virginia, USA                            fax: +1-703-262-5367