Aaron Oakley added the comment:
>From memory, the use case at the time was using a custom TreeBuilder sub-class
>fed into a builtin XMLParser object. The code would construct a builder
>separately and keep a reference to it around. The builder would delegate calls
>to start(), data(), end(), and close() to super and save the completed tree
>when its close() was called.
my_builder = CustomTreeBuilder()
et_parser = ET.XMLParser(target=my_builder)
for (evt, elem) in ET.iterparse("...", events, parser=et_parser):
pass # Do first processing
tree = my_builder.root # Saved tree
It was done like this initially so that some data (I can't recall exactly what)
from the XML input could be processed first very conveniently using the parse
events from iterparse while allowing the whole tree to be retrieved afterwards.
That said, the project later moved to using lxml for various features not
contained in xml.etree.ElementTree, and I don't think the process I described
is still being used.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17902>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
