[Python-Dev] PEP 492: async/await in Python; v3

[Yury Selivanov]

Greg,

On 2015-04-29 5:12 AM, Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov 
>> <yselivanov.ml at gmail.com <mailto:yselivanov.ml at gmail.com>> wrote:
> >
>>     Why StopAsyncIteration?
>>     '''''''''''''''''''''''
>>
>> I keep wanting to propose to rename this to AsyncStopIteration.
>
> +1, that seems more consistent to me too.
>
>>     And since PEP 479 is accepted and enabled by default for coroutines,
>>     the following example will have its ``StopIteration`` wrapped into a
>>     ``RuntimeError``
>
> I think that's a red herring in relation to the reason
> for StopAsyncIteration/AsyncStopIteration being needed.
> The real reason is that StopIteration is already being
> used to signal returning a value from an async function,
> so it can't also be used to signal the end of an async
> iteration.


When we start thinking about generator-coroutines (the ones that
combine 'await' and 'async yield'-something), we'll have to somehow
multiplex them to the existing generator object (at least that's
one way to do it).  StopIteration is already extremely loaded
with different special meanings.

[..]
>
>> Does send() make sense for a native coroutine? Check PEP 380. I think 
>> the only way to access the send() argument is by using ``yield`` but 
>> that's disallowed. Or is this about send() being passed to the 
>> ``yield`` that ultimately suspends the chain of coroutines?
>
> That's made me think of something else. Suppose you want
> to suspend execution in an 'async def' function -- how do
> you do that if 'yield' is not allowed? You may need
> something like the suspend() primitive that I was thinking
> of adding to PEP 3152.

We do this in asyncio with Futures.  We never combine 'yield' and
'yield from' in a @coroutine.  We don't need 'suspend()'.

If you need suspend()-like thing in your own framework, implement
an object with an __await__ method and await on it.

>
>>     No implicit wrapping in Futures
>>     -------------------------------
>>
>>     There is a proposal to add similar mechanism to ECMAScript 7 
>> [2]_.  A
>>     key difference is that JavaScript "async functions" always return a
>>     Promise. While this approach has some advantages, it also implies 
>> that
>>     a new Promise object is created on each "async function" invocation.
>
> I don't see how this is different from an 'async def'
> function always returning an awaitable object, or a new
> awaitable object being created on each 'async def'
> function invocation. Sounds pretty much isomorphic to me.
>

Agree.  I'll try to reword that section.

Thanks,
Yury