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>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
