Stefan Behnel added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17741> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
