Antoine Pitrou added the comment: > > Well, I would rather like to understand yours. > > My point is that the IncrementalParser uses a TreeBuilder that builds > an XML tree in the back. So I'm wondering why you are saying that it > doesn't build a tree.
Unless I'm reading it wrong, when _setevents() is called, the internal hooks are rewired to populate the events list, rather than call the corresponding TreeBuilder methods. So, yes, there's a TreeBuilder somewhere, but it stands unused. (the _setevents() method already existed on the C impl, by the way. I added it to the Python impl to make things more regular and avoid two separate iterparse() implementations) > And my > point is that we shouldn't duplicate the existing *data entry* > interface for that, especially not under different names for > identical functionality, but only add an interface to access those > events as *output*, i.e. to add the bit of the API that's actually > missing. What difference would that make? In the end, you mustn't mix event-driven/non-blocking and cumulative/blocking styles of programming, so having two separate APIs doesn't strike me as a problem (it may be a good thing actually, for clarity reasons). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17741> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
