Stefan Behnel wrote:

Sébastien Boisgérault wrote:
Agreed. I started the port with elementtree 1.3 (alpha) because it has
interesting features AND a set of unit tests that were helping me with
the port.

Ah, so you need ET unit tests, right?

What about these:
Good ! Another source of tests. I will look into this. So far, thanks to jython-dev help, I have found the following tests:

  - '' and '' from Python 2.5 source distribution,
  - the '' that ships with every ElementTree download from (all versions and not only 1.3, my mistake),

and validation that comes from 3rd-party libraries that use ElementTree or expat, including:

  - FormEncode
  - Genshi

I will try to publish some test-related info on the wiki when I'll find enough time.

You'll have to strip the "" down a bit to get it to work on

Also note that this also tests against ET 1.3, so a few tests will fail
exactly for that reason when you go down to 1.2.x. Just take them out (or
replace iter() by getiterator(), or whatever seems obvious).

But the current strategy of the project is to reimplement (a part of)
expat on top or Java org.xml.sax features, so that ElementTree 1.2.6
(used in Python 2.5) and ElementTree 1.3 alpha would work "out of
the box".

Plus, it gives us the missing module 'for free'. Yep, that's the
perfect strategy. :)
However, there are some significant differences between expat and Java org.xml.sax models, so I fear that some advanced yet-to-be-documented features of expat cannot be supported. ElementTree being using mostly the basic features of expat, we can expect a rather good support for ElementTree, and therefore for other libs that are built on top of it (such as FormEncode). On the other hand, for toolkit such as Genshi, that use directly expat (and a rather large set of features), I doubt that my implementation will fly ...

These limitations may include expat "chunk-by-chunk"  XML parsing, and the external entity and DTD related stuff.



Thanks for the work you put into this!