> IMO “yield from coroutine_iterator” might be plausable for some strange combination of 3.4 code and a 3.5 coroutine, but I think it would be rare. And if you added a check in __await__() then the using “await” wouldn’t need to rely on next() raising the RuntimeError.
Adding the check *only* to __await__ will allow you to wrap an exhausted coroutine in an 'asyncio.Task' and await on it (the await will do nothing, which this patch fixes).
I think it's important to fix all coroutines' APIs to throw an error if they're manipulated in any way after being exhausted/closed, that's why I decided to fix the lower level.
To be honest, I don't care too much about 'yield from coro.__await__()' raising a RuntimeError (if the coro is an 'async def' coroutine that *is* closed/exhausted). To me it's a clear behaviour. Again, coroutine-iterators (objects returned by native coroutines from their __await__() method) aren't classical iterators meant to produce a fibonacci sequence in a for..in loop. They are a low level interface to their coroutine objects.