Author scoder
Recipients eli.bendersky, flox, jcea, pitrou, python-dev, scoder
Date 2013-08-09.11:32:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1376047926.53.0.437156420144.issue17741@psf.upfronthosting.co.za>
In-reply-to
Content
Actually, let me take that last paragraph back. There is an Obvious Way to do it, and that's the feed() and close() methods. They are the existing and established ElementTree interface for incremental parsing. The fact that close() doesn't clean up all state is IMHO a minor issue. The state will be cleaned up automatically once the iteration terminates, and that's the normal behaviour of iterators. So it actually fits both protocols quite nicely.

I'd just leave the stream protocol out completely here. For one, the implementation isn't complete anyway (the connection_*() methods don't make much sense), and as I said, it's not very useful to consider the parser a general end-point to that protocol.

I'd also suggest returning the iterator over the remaining events from close(), just like the TreeBuilder returns the tree. That covers the (less common) use case of first parsing everything and then processing the events. I'll add another patch that does that.
History
Date User Action Args
2013-08-09 11:32:06scodersetrecipients: + scoder, jcea, pitrou, eli.bendersky, flox, python-dev
2013-08-09 11:32:06scodersetmessageid: <1376047926.53.0.437156420144.issue17741@psf.upfronthosting.co.za>
2013-08-09 11:32:06scoderlinkissue17741 messages
2013-08-09 11:32:06scodercreate