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

[Eli Bendersky]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130826/3251baaa/attachment.html>