[Python-Dev] ElementTree - Why not part of the core? (fwd)

Sun Dec 11 17:48:51 CET 2005

Martin v. Löwis wrote:
> That's primarily for the author of the software to decide, at this
> point. Fredrik Lundh would have to offer it for contribution first.

I've already done that, as others have noted. Everything I release
under a Python-compatible license is available for bundling with the
python core.
> I don't know what his current position is, but I think it is unlikely
> that he will contribute it: in the past, he often indicated that he
> a) dislikes the growth of the standard Python library

Yes and no; replacing stale or incomplete parts with better libraries
are usually a very good idea (the subprocess library is a recent example)
But it's correct that I want the core library (the parts that lives in the
python development trunk) to get smaller; that doesn't necessarily mean
that a standard Python distribution should ship with a smaller library.
> b) dislikes forking his own branch for inclusion in another package
> (which would happen if he contributed one version for the
> standard library, and would continue to maintain the code
> outside of Python also).

I want to avoid things like sgmlop (which was forked, and is currently
shipped with broken bindings in a mostly unmaintained library). I also
want to avoid problems for people who've come to rely on the deve-
lopment and release approach I've used since I started shipping Python
software in 1995.
But if everyone is aware that this is a bundled piece of software, and
the development and maintenance process is updated accordingly, that
shouldn't be a problem.
Here's a plan:
 - I check in an existing elementtree release in a separate location in
 the svn.python.org source tree. e.g.
 svn.python.org/kits/elementtree-1.2.6-20050316
 this will make it clear that this is external software, and it also
 provides a reference point for tracking down local changes
 - we decide what elementtree modules to include, and where to place
 them, and copy them to the python trunk.
 (suggestion: either directly under xml, or under xml.etree)
 - I adapt the elementtree selftest so it runs under Python's test suite
 - I convert the pythondoc pages for the included modules to match the
 library reference format (someone will have to help with the markup
 here)
 - when new stable releases appear upstream, add to kits and copy
 relevant modules. update/tweak docs as necessary.
 - delegate incoming bug reports / patches to the upstream maintainer.
and, optionally
 - sort out expat bundling issues, and include cElementTree as well
 (using the same approach as above).
whaddya think?
</F>