This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients eli.bendersky, flox, jcea, pitrou, python-dev, scoder
Date 2013-08-09.15:14:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> > 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).
Date User Action Args
2013-08-09 15:14:39pitrousetrecipients: + pitrou, jcea, scoder, eli.bendersky, flox, python-dev
2013-08-09 15:14:39pitroulinkissue17741 messages
2013-08-09 15:14:39pitroucreate