<html><head/><body><html><head></head><body>How about StreamParser? I mean, even if it isn't quite the same, that name would still make sense.<br><br><div class="gmail_quote">Eli Bendersky <eliben@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 26, 2013 at 8:57 AM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br />
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le Mon, 26 Aug 2013 17:44:41 +0200,<br />
Simon Cross <<a href="mailto:hodgestar%2Bpythondev@gmail.com">hodgestar+pythondev@gmail.com</a>> a écrit :<br />
<div class="im">> On Mon, Aug 26, 2013 at 2:51 PM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>><br />
> wrote:<br />
> > Because this API is mostly useful when the data is received (*) at a<br />
> > slow enough speed - which usually means from the network, not from a<br />
> > hard drive.<br />
><br />
> It looks like all the events have to be ready before one can start<br />
> iterating over .events() in the new API? That doesn't seem that useful<br />
> from an asynchronous programming perspective and .data_received() and<br />
> .eof_received() appear to be thin wrappers over .feed() and .close()?<br />
<br />
</div>What do you mean, "all events have to be ready"?<br />
If you look at the unit tests, the events are generated on-the-fly,<br />
not at the end of the document.<br />
(exactly the same as iterparse(), except that iterparse() is blocking)<br />
<br />
Implementation-wise, data_received() and eof_received() are not thin<br />
wrappers over feed() and close(), they rely on an internal API to get<br />
at the generated events (which justifies putting the functionality<br />
inside the etree module, by the way).<br /></blockquote></div><br /></div><div class="gmail_extra">Antoine, you opted out of the tracker issue but I feel it's fair to let you know that after a lot of discussion with Nick and Stefan (*), we've settled on renaming the input methods to feed & close, and the output method to read_events. We are also considering a different name for the class.<br />
<br /></div><div class="gmail_extra">I've posted with more detail and rationale in <a href="http://bugs.python.org/issue17741">http://bugs.python.org/issue17741</a>, but to summarize:<br /><br /></div><div class="gmail_extra">
The input-side of IncrementalParser is the same as the plain XMLParser. The latter can also be given data incrementally by means of "feed". By default it would collect the whole tree and return it in close(), but in reality you can rig a custom target that does something more fluid (though not to the full extent of IncrementalParser). Therefore it was deemed confusing to have different names for this. Another reason is consistency with xml.sax.xmlreader.IncrementalParser, which also has feed() and close().<tt class=""><span class=""><br />
</span></tt></div><div class="gmail_extra"><br /></div><div class="gmail_extra">As for the output method name, Nick suggested that read_events conveys the destructive nature of the method better (by analogy to file/stream APIs), and others agreed.<br />
<br /></div><div class="gmail_extra">As for the class name, IncrementalParser is ambiguous because it's not immediately clear which side is incremental. Input or output? For the input, it's no more incremental than XMLParser itself, as stated above. The output is what's different here, so we're considering a few candidates for a better name that conveys the meaning more precisely.<br />
<br /></div><div class="gmail_extra">And to reiterate, I realize that it's unpleasant for you to have this dug up after it has already been committed. I assume the blame for not reviewing it in more detail originally. However, I feel it would still be better to revise this now than just leave it be. APIs added to stdlib are cooked in there for a *long time*. Alternatively, Nick suggested granting this API a "provisional" status (PEP 411), and that's an option if we don't manage to reach some sort of consensus.<br />
</div><div class="gmail_extra"><br /></div><div class="gmail_extra">Eli<br /><br />(*) Well, to be completely precise, Stefan is still opposed to the whole idea.<br /></div><div class="gmail_extra"><br /><br /><br /><br /></div></div>
<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px"><hr /><br />Python-Dev mailing list<br />Python-Dev@python.org<br /><a href="http://mail.python.org/mailman/listinfo/python-dev">http://mail.python.org/mailman/listinfo/python-dev</a><br />Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com">http://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.</body></html></body></html>