Yury Selivanov added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25887> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
