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

Antoine Pitrou solipsis at pitrou.net
Tue Aug 27 10:09:14 CEST 2013

Le Tue, 27 Aug 2013 09:58:57 +0200,
Simon Cross <hodgestar+pythondev at gmail.com> a écrit :
> On Mon, Aug 26, 2013 at 5:57 PM, Antoine Pitrou <solipsis at pitrou.net>
> 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.

At most, you're gonna poll events() after calling data_received()
(there's no other way some events can be generated, after all).
You can also poll it less often, depending on how often you're
interested in new events. That is, it is amenable to both push and pull

> 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.

That would be sensible to do if Deferred was a construct shared amongst
major async frameworks, but it isn't ;-)
(and it looks like Guido won't include a Deferred-alike in PEP 3156)

Letting people "poll" events() lets them plug any async-callback-firing
primitive they like, almost trivially.



More information about the Python-Dev mailing list