As suggested by the author or ElementTree (Fredrik Lundh) I just copied 'SimpleXMLTreeBuilder' from a previous version. That worked when creating a tree from a string:
from elementtree import ElementTree, SimpleXMLTreeBuilder
memFile = StringIO.StringIO(someXmlString)
tree = ElementTree.parse(memFile, SimpleXMLTreeBuilder.TreeBuilder())
I think it would indeed be a good idea to swap out ElementTree's calls to C libs with calls to java libs, but:
- Will it be really faster? (I must say that I get the feeling that the above code is pretty slow)
- Only the treebuilder relies on 'expat' (the C lib), which can easily be circumvented by using ElementTree's own 'SimpleXMLTreeBuilder'. The reason Fredrik Lundh throws out the latter in the latest version is: "This module used xmllib to do the parsing, but since expat has been available from since around Python 2.0 or so, keeping the old support is pretty pointless." (See: http://effbot.org/zone/elementtree-13-intro.htm). Well, for jython it isn't really pointless. If 'SimpleXMLTreeBuilder' stays around Jython doesn't have to provide a custom ElementTree lib.
Just out of curiosity, would it make sense to Java-ize the "real"
ElementTree (or lxml) library by swapping out the lib's internal
calls to c libraries w/ calls to java xml libraries while keeping the
python interface to them the same?
This way, scripts will be portable between Jython and CPython and
still be relatively performant, no? If, as I'm assuming, using the
all-python version in this case causes a severe(?) penalty hit.