[Python-Dev] please back out changeset f903cf864191 before alpha-2

[Ryan]

How about StreamParser? I mean, even if it isn't quite the same, that name would still make sense.

Eli Bendersky <eliben at gmail.com> wrote:

>On Mon, Aug 26, 2013 at 8:57 AM, Antoine Pitrou <solipsis at pitrou.net>
>wrote:
>
>> 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).
>>
>
>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.
>
>I've posted with more detail and rationale in
>http://bugs.python.org/issue17741, but to summarize:
>
>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().
>
>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.
>
>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.
>
>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.
>
>Eli
>
>(*) Well, to be completely precise, Stefan is still opposed to the
>whole
>idea.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Python-Dev mailing list
>Python-Dev at python.org
>http://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>http://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130826/c85b5e2b/attachment-0001.html>