Yury Selivanov

> But what is the failure mode if you don't use wait_closed()? The stream > _does_ get closed, just on the next trip through the loop, right? Yes. It's not...

I agree with Guido, if we want to fix this let's add a distinct new method. The ship for re-designing "close()" has sailed.

> About asyncio.forever(), wouldn't it be simpler to have a wrapper around loop.add_signal_handler(SIGINT, ...)? For instance: This would work to support signals. I want `asyncio.forever()` to support `try..finally` blocks regardless...

> Sure, add this. I don't have time for a review though. I've experimented a little bit, and it turns out that it's not that hard to implement the `asyncio.forever()`...

> So forever is just sleep infinity? Why do we need that? It's similar but not the same. It's designed to replace uses of `loop.run_forever()`, moving the program cleanup logic...

@gvanrossum > -1. Something that's only meant to be used at the top level doesn't deserve > to be a coroutine IMO. Normally yes, I agree. Although I don't think...

> That's also ambiguous (is it a verb or a noun?). And the issue of whether I think I came up with a solution, please see below. > it would...

> IIRC people are currently using a bare yield as the equivalent of sleep(0) > -- just bounce to the loop, run all callbacks, and then continue. How can >...

> Also frankly run_in_executor() is a pretty clumsy API due to the initial parameter that is usually None. Is it really important enough to have this? (Again, I worry that...

> Again, if my voice counts, the thing that I would like to have is a simple-minded run (I could imagine this could be the same for other non-experts in...