Le Mon, 26 Aug 2013 17:44:41 +0200, Simon Cross <hodgestar+pythondev at gmail.com> a écrit : > On Mon, Aug 26, 2013 at 2:51 PM, Antoine Pitrou <solipsis at pitrou.net> > wrote: > > Because this API is mostly useful when the data is received (*) at a > > slow enough speed - which usually means from the network, not from a > > hard drive. > > It looks like all the events have to be ready before one can start > iterating over .events() in the new API? That doesn't seem that useful > from an asynchronous programming perspective and .data_received() and > .eof_received() appear to be thin wrappers over .feed() and .close()? 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) Implementation-wise, data_received() and eof_received() are not thin wrappers over feed() and close(), they rely on an internal API to get at the generated events (which justifies putting the functionality inside the etree module, by the way). Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4