iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Take over PEP 206, renaming it to 'Python Advanced Library'

This commit is contained in:
Andrew M. Kuchling 2005-06-27 20:31:59 +00:00
parent 780ec3787e
commit e761d70b6f
2 changed files with 87 additions and 111 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
pep-0000.txt
View File

@ -67,7 +67,7 @@ Index by Category
Open PEPs (under consideration)
I 206 2.0 Batteries Included Zadka
I 206 Python Advanced Library Kuchling
S 209 Adding Multidimensional Arrays Barrett, Oliphant
S 228 Reworking Python's Numeric Model Zadka, GvR
S 237 Unifying Long Integers and Integers Zadka, GvR
@ -248,7 +248,7 @@ Numerical Index
SF 203 Augmented Assignments Wouters
SR 204 Range Literals Wouters
S 205 Weak References Drake
I 206 2.0 Batteries Included Zadka
I 206 Python Advanced Library Kuchling
SF 207 Rich Comparisons GvR, Ascher
SF 208 Reworking the Coercion Model Schemenauer, Lemburg
S 209 Adding Multidimensional Arrays Barrett, Oliphant

194
pep-0206.txt
View File

@ -1,133 +1,109 @@
PEP: 206
Title: 2.0 Batteries Included
Title: Python Advanced Library
Version: $Revision$
Author: moshez@zadka.site.co.il (Moshe Zadka)
Python-Version: 2.0
Author: A.M. Kuchling <amk@amk.ca>
Status: Draft
Introduction
This PEP describes the `batteries included' proposal for Python
2.0, the fat distribution containing commonly used third party
extension modules. This PEP tracks the status and ownership of
this proposal, slated for introduction in Python 2.0. It contains
a description of the proposal and outlines how to support it.
This PEP describes the Python Advanced Library, a collection of
high-quality and frequently-used third party extension modules.
Batteries Included Philosophy
The Python source distribution always maintained the philosophy of
"batteries included" -- having a rich and versatile standard
The Python source distribution has long maintained the philosophy
of "batteries included" -- having a rich and versatile standard
library which is immediately available, without making the user
download separate packages. This gives the Python language a head
start in many projects. However, the Python standard library
often relies on important Open Source libraries which might be
unavailable on many computers, so that the user has to separately
download and compile those. Some examples are the zlib
compression library, and the gmp number manipulation library.
start in many projects.
The original coinage of the term "batteries included" can be found
here:
However, the standard library modules aren't always the best
choices for a job. Some library modules were quick hacks
(e.g. calendar, commands), some were designed poorly and are now
near-impossible to fix (cgi), and some have been rendered obsolete
by other, more complete modules (binascii offers the same features
as the binhex, uu, base64 modules). This PEP describes a list of
third-party modules that make Python more competitive for various
application domains, forming the Python Advanced Library.
http://www.uk.research.att.com/~fms/ipc7/tr-1998-9.html
The Proposed Solution
The proposed solution is to maintain an alternate form of distribution,
nicknamed the "sumo" interpreter. It will be structured as a core
interpreter + extra useful libraries. In addition, the build procedure
will be changed to build those libraries by default, and build the Python
modules which rely on them linked against those libraries. Individual
users will still be able to link the Python modules against already
installed libraries, or disable them completely.
Additionally, some Open Source third-party Python modules will
also be distributed in the "sumo" distribution. The
difference between those and external libraries is that the former
are distributed in order to make the Python distribution self
contained, and the latter are added so there will be new
functionality in out-of-the-box Python.
Python Advanced Library
Since it is decided that the additions to the interpreter will live
in a seperate directory, they can even be distributed seperately,
as an additional library. This is called the "Python Advanced Library",
or PAL. This will also solve the problem of an advanced library module
failing -- the core interpreter will still be built, tested and installed.
Since the compilation of the other modules be helped by Python scripts,
it is quite possible that it will even install as many modules as it
can.
Suggested Libraries and Modules
Here is the tentative list of libraries which are proposed to be
dealt with in this manner, and where they can be downloaded:
zlib -- http://www.info-zip.org/pub/infozip/zlib/zlib.tar.gz
expat -- ftp://ftp.jclark.com/pub/xml/expat.zip
Tcl -- http://dev.scriptics.com:80/download/tcl/tcl8_3/tcl8.3.1.tar.gz
Tk -- http://dev.scriptics.com:80/download/tcl/tcl8_3/tk8.3.1.tar.gz
PIL -- http://www.pythonware.com/downloads/Imaging-1.1.tar.gz
libjpeg -- ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz
ncurses -- ftp://dickey.his.com/ncurses/ncurses.tar.gz
TBD, the following:
NumPy -- http://download.sourceforge.net/numpy/Numerical-15.3.tgz
Pmw -- ftp://ftp.dscpl.com.au/pub/pmw/Pmw.0.8.4.tar.gz
BLT -- ftp://ftp.tcltk.com/aa004735/pub/blt/BLT2.4u.tar.gz
piddle -- http://download.sourceforge.net/piddle/piddle-1.0b7.tgz
Connection to Distutils
Since Python 2.0 comes with a new mechanism of distributing Python
modules, called ``distutils'', we should be able to use it. Specificially,
since distutils has the capability or building Python modules in an
automatic fashion, it is hoped that some of the work will consist in
creating a new directory with the source, and having the ``super-make''
run "./setup --install" in those directories. This should at least take
care of PIL, NumPy and Pmw. In addition, it is hoped that this mechanism
will be easy enough to add other Python modules as user requests direct
us.
The deliverable is a set of scripts that will retrieve, build, and
install the packages for a particular application domain. The
Python Package Index now contains enough information to let
software automatically find packages and download them, so the
time is ripe to implement this.
Currently this document doesn't suggest *removing* modules from
the standard library that are superseded by a third-party module.
That's difficult to do because it entails many backward-compatibility
problems, so it's not worth bothering with now.
Please suggest additional domains of interest.
Domain: Web tasks
XML parsing: ElementTree + SAX.
URL retrieval: libcurl? other possibilities?
HTML parsing: mxTidy? HTMLParser?
Async network I/O: Twisted
RDF parser: ???
HTTP serving: ???
HTTP cookie processing: ???
Web framework: A WSGI gateway, perhaps? Paste?
Graphics: PIL, Chaco.
Domain: Scientific Programming
Numeric: Numeric, SciPy
Graphics: PIL, Chaco.
Domain: Application Development
GUI toolkit: ???
Graphics: Reportlab for PDF generation.
Domain: Education
Graphics: PyGame
Software covered by the GNU General Public License
While many Python modules rely on software distributed under the
GNU General Public License and the GNU Lesser General Public
License, no such sources are proposed here to be added to the
sumo interpreter. Currently, the Python interpreter is
distributed under a closed-source-friendly license, which means
that it is possible to include it in a closed source product.
Making redistributers worry about which parts they need to remove
to make closed-source redistribution legal might cost more then
the benefits.
How It Is Implemented
Sumo-Python is basically be a set of scripts, which download
a Python source tarball, and source tarballs for all the modules.
Then it unpacks everything, modifies Setup.in (or whatever mechanism
will be in place by Python 2.1, and puts in a little
shell script which builds everything. Then it will repack it
into the huge tarball which will be a sumo-python-version.tar.gz,
which users can then download and install.
Inside the tarball, running the script
build-everything [--prefix ...]
Will compile and install a sumo interpreter into specified prefix.
Some of these third-party modules are covered by the GNU General
Public License and the GNU Lesser General Public License.
Providing a script to download and install such packages, or even
assembling all these packages into a single tarball or CD-ROM,
shouldn't cause any difficulties with the GPL, under the "mere
aggregation" clause of the license.
Open Issues
ESR also mentioned libpng, but I don't know of a Python module
that uses it.
What other application domains are important?
How to make PAL as easy to build as the whole Sumo Python?
Should this just be a set of Ubuntu or Debian packages? Compiling
things such as PyGame can be very complicated and may be too
difficult to automate.
Acknowledgements
The PEP is based on an earlier draft PEP by Moshe Zadka, titled
"2.0 Batteries Included."
Local Variables: