This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yselivanov
Recipients asvetlov, brett.cannon, gvanrossum, martin.panter, ncoghlan, vstinner, yselivanov
Date 2016-01-12.02:34:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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 loop.  They are a low level interface to their coroutine objects.
Date User Action Args
2016-01-12 02:34:49yselivanovsetrecipients: + yselivanov, gvanrossum, brett.cannon, ncoghlan, vstinner, asvetlov, martin.panter
2016-01-12 02:34:49yselivanovsetmessageid: <>
2016-01-12 02:34:49yselivanovlinkissue25887 messages
2016-01-12 02:34:49yselivanovcreate