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 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 <>
> 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.
Date User Action Args
2013-08-09 14:09:38scodersetrecipients: + scoder, jcea, pitrou, eli.bendersky, flox, python-dev
2013-08-09 14:09:38scodersetmessageid: <>
2013-08-09 14:09:38scoderlinkissue17741 messages
2013-08-09 14:09:38scodercreate