On Jun 6, 2016, at 12:23 PM, Yury Selivanov
However, with the current PEP 492 design, the above code would be invalid! The interpreter expects __aiter__ to return a coroutine, not an async generator.
Yes, I remember asking about the reason behind __aiter__ being an awaitable during the original PEP 492 review process. You added an explanation to the PEP but I don’t think we ever had an example where this was needed. I’m +1 to resolve this now.
The proposed patch fixes the __aiter__ in a backwards compatible way:
1. ceval/GET_AITER opcode calls the __aiter__ method.
2. If the returned object has an '__anext__' method, GET_AITER silently wraps it in an awaitable, which is equivalent to the following coroutine:
async def wrapper(aiter_result): return aiter_result
3. If the returned object does not have an '__anext__' method, a DeprecationWarning is raised.
There’s a problem with this approach. It will force people to write deprecated code because you never know if your library is going to run on 3.5.0 or 3.5.1. Barry, Ubuntu wily, xenial and yakkety currently package 3.5.0 or 3.5.1. When 3.5.2 is going to get released, are they going to get it? I’m pretty sure wily isn’t and yakkety is but just wanted to confirm; especially with xenial being an LTS release. -- Not-that-i-see-a-different-way-out’sly yours, Ł