Message194732
> 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:38 | scoder | set | recipients:
+ scoder, jcea, pitrou, eli.bendersky, flox, python-dev |
2013-08-09 14:09:38 | scoder | set | messageid: <1376057378.36.0.0473196005399.issue17741@psf.upfronthosting.co.za> |
2013-08-09 14:09:38 | scoder | link | issue17741 messages |
2013-08-09 14:09:38 | scoder | create | |
|