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

["Martin v. Löwis"]

Fredrik Lundh 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 see a difference here, though, between "offer for contribution"
and "make available for bundling". To my knowledge, you never said
(until now) "I would like to incorporate ElementTree into the Python CVS
repository, and thus have it become part of future Python releases".

> 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.

I know you said this before; I could never understand what you mean
by that. I would always assume that we only ship what is in the source
repository (plus, for the specific case of Windows binaries, what is
documented in PCbuild/readme.txt). So how can the trunk get smaller,
yet the distribution larger?

>   - 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

Ah, so you want what CVS calls a "vendor branch": code that is
externally maintained, and imported from time to time.

Clearly, "local" (i.e. python.org) changes are one primary issue,
so we should agree on an update process - I would personally prefer
one that allows for merging (in the "svn merge" sense).

The other issue is, of course, the question whose job it is to actually
perform the updates. Would you expect to do that yourself, or would
you expect somebody else does that?

I'm still troubled that you keep saying that sgmlop "was forked". I
had not been PyXML maintainer long enough to remember the precise
history of things, but it was certainly the case that you could have
updated it all the time - you still have write permission to the
PyXML repository.

>   - 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)

Would there be a reason not to include the entire elementtree package?
Either xml.etree, or xml.tree would be fine with me, -0 for putting
it directly into xml.

>   - I adapt the elementtree selftest so it runs under Python's test suite

Good.

>   - I convert the pythondoc pages for the included modules to match the
>     library reference format (someone will have to help with the markup
>     here)

Would you then start using the tex sources as your primary sources, or
would this conversion need to be done every time the package is updated?

>   - when new stable releases appear upstream, add to kits and copy
>     relevant modules.  update/tweak docs as necessary.

The "tweak docs" part sounds somewhat worrying. Of course, you could run
"svn diff" on the old and new version, to see what doc strings have
changed or appeared - but that might be quite some work.

>   - delegate incoming bug reports / patches to the upstream maintainer.

Would it be sufficient to set you as the "Assigned To" in the SF
tracker? I don't see specific bug reporting instructions on the
elementtree page.

> and, optionally
> 
>   - sort out expat bundling issues, and include cElementTree as well
>     (using the same approach as above).

Not sure what this would be; we probably can look at it again when
we are done with the first part.

> whaddya think?

Overall, sounds like a good plan.

Regards,
Martin