> > 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).