4 ms·

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 t

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 11y ago
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 11y ago
  Yeah, it seems like the work on asyncio may do what I want; I will update the post.