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