Message258059
> 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. |
|
Date |
User |
Action |
Args |
2016-01-12 02:34:49 | yselivanov | set | recipients:
+ yselivanov, gvanrossum, brett.cannon, ncoghlan, vstinner, asvetlov, martin.panter |
2016-01-12 02:34:49 | yselivanov | set | messageid: <1452566089.77.0.131371591519.issue25887@psf.upfronthosting.co.za> |
2016-01-12 02:34:49 | yselivanov | link | issue25887 messages |
2016-01-12 02:34:49 | yselivanov | create | |
|