Simon Cross, 27.08.2013 09:58: > On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou wrote: >> What do you mean, "all events have to be ready"? >> If you look at the unit tests, the events are generated on-the-fly, >> not at the end of the document. >> (exactly the same as iterparse(), except that iterparse() is blocking) > > So you have to poll .events()? That also seems unhelpful from an event > driven programming perspective. > > What I'm driving at is that I'd expect to have access to some sort of > deferred that fires when the next event is ready to be processed and I > don't see that here.
The idea is that you pass data into the parser and then ask read_events() for an event iterator. If/When that's empty, you're done. No repeated polling or anything, just all in one shot whenever data is available. It's a really nice interface by design, just badly integrated into the existing API. Stefan _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
