
Extending Python’s generators to support mainloops - chromano
http://chromano.me/2015/10/02/python-mainloop-generators.html
======
jonathaneunice
I did not understand the highly synchronous, sequential, blocking behavior of
the code examples. That would absolutely make the events example not work. Or
is it implicit that an asynchronous operation would replace today's blocking
`next()`? That `itertools.consume()` or the final `next()` would provide an
async upgrade, similar to the way Unix's `select()` works? That was never
explicitly mentioned...but is the only way this pattern would make larger
sense / scale usefully.

~~~
chromano
Thanks for the feedback. I think the post has much to be improved, but the
idea was to get an idea of how that would be useful for other developers --

As for the `next()` and `consume()` approaches, yes, that would basically
combine multiple generators in one and not block on any of them.

I will update the post with more information and also take into consideration
all the work that has been done on asyncio module for Python3.4.

~~~
jonathaneunice
If we're talking about a general purpose event provider/consumer API that
takes into account that some event sources will be voluble, while others will
be almost always silent/blocked, then that's a real upgrade. It could bring a
real event-oriented capability to generators. You see bits and pieces of that
now--attempts to use generators with greenlets and coroutines, say. But until
the 3.4 asyncio work, GvR hasn't seemed sufficiently interested/invested to
make a big step forward on event processing idioms. Now he is.

~~~
chromano
Yeah, it seems like the work on asyncio may do what I want; I will update the
post.

