[Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2

[Stefan Behnel]

Florent Xicluna, 20.02.2010 11:53:
> Stefan Behnel writes:
>> None of theses features is really required to hold for anything but the
>> current as-is implementation.
> 
> I agree.
> 
>> So my impression is that many of the tests try to provide guarantees where
>> they cannot or should not exist, and even where the output is clearly
>> non-conforming with respect to standards. I don't think it makes sense to
>> put these into a regression test suite.
> 
> The test suite in the stdlib should try to cover every piece of code, even
> implementation details and edge cases.

It shouldn't test for un(der)defined or non-guaranteed behaviour, bugs or
the /absence/ of certain features, though. Apart from that, I agree with
the following:

> It guarantees that the implementation
> details do not change between minor releases. And it helps identify regression
> or evolution of the behavior when the library is updated.


> Additionally, these tests ensure that the C implementation can be used as a
> drop-in replacement of the Python implementation. It is a request expressed by
> many users of the "xml.etree" package.

That's certainly a worthy goal, but it's orthogonal to the interest of
changing/improving/evolving ElementTree itself. The goal here is to make
cElementTree compatible with ET, without any impact on ET.

I agree with Fredrik that there are a number of additional features in ET
1.3 (and lxml 2.x) that can be easily added to the existing API, e.g. the
element.extend() method. Other new features (and certainly the incompatible
changes) are a lot more controversial, though.


>> That said, I should add that lxml's test suite includes about 250 unit
>> tests that work with (and adapt to) lxml.etree, ElementTree and
>> cElementTree, in Py2.3+ and Py3.x, and with ET 1.2 and ET 1.3. Although
>> certainly not a copy&run replacement, those should be much better suited to
>> accompany the existing stdlib tests.
>
> Interesting. I may add these tests to the test_suite, if they are not
> completely redundant.

They certainly were not redundant with the original tests that shipped with
ET, and they test all sorts of funny cases. The main files are

https://codespeak.net/viewvc/lxml/trunk/src/lxml/tests/test_elementtree.py?view=markup
https://codespeak.net/viewvc/lxml/trunk/src/lxml/tests/test_io.py?view=markup

There are also a number of ET API tests in other parts of the test suite
(mostly test_etree.py, also test_unicode.py). Some of them would work with
ET but produce different results due to various reasons, including the fact
that lxml.etree behaves "more correct" in some cases. The latter are the
kind of tests that I would prefer not to see in the stdlib test suite.

Stefan