Author scoder
Recipients eli.bendersky, flox, jcea, pitrou, python-dev, scoder
Date 2013-08-09.14:09:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1376057378.36.0.0473196005399.issue17741@psf.upfronthosting.co.za>
In-reply-to
Content
> The point is not to build a tree of potentially unbounded size (think
> XMPP). The point is to yield events in a non-blocking way (iterparse()
> is blocking, which makes it useless for non-blocking applications).

Ok, but that's the only difference. Instead of getting the events from the parser, you could equally well get them from the TreeBuilder, also in a non-blocking way.

Sticking this functionality into a parser target object has the advantage that the parser interface wouldn't have to change. So, instead of introducing an entirely new parser interface, we'd just add a class that can be used as a parser target and provides an additional events() method. That's a substantially less invasive API change.


> An IncrementalTreeBuilder wouldn't have much point IMO. It is not more
> costly to accumulate a string and parse it at the end, than to
> progressively build a growing XML tree.

I don't think I understand what you mean.
History
Date User Action Args
2013-08-09 14:09:38scodersetrecipients: + scoder, jcea, pitrou, eli.bendersky, flox, python-dev
2013-08-09 14:09:38scodersetmessageid: <1376057378.36.0.0473196005399.issue17741@psf.upfronthosting.co.za>
2013-08-09 14:09:38scoderlinkissue17741 messages
2013-08-09 14:09:38scodercreate