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 <2009715590.52992769.1376061273289.JavaMail.root@zimbra10-e2.priv.proxad.net>
In-reply-to <1376060386.37.0.514540235802.issue17741@psf.upfronthosting.co.za>
Content
> > 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).
History
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