[Python-Dev] async/await in Python; v2

[Yury Selivanov]

Hi Greg,

On 2015-04-22 2:05 AM, Greg Ewing wrote:
> Yury Selivanov wrote:
>> 1. CO_ASYNC flag was renamed to CO_COROUTINE;
>>
>> 2. sys.set_async_wrapper() was renamed to
>>    sys.set_coroutine_wrapper();
>>
>> 3. New function: sys.get_coroutine_wrapper();
>>
>> 4. types.async_def() renamed to types.coroutine();
>
> I still don't like the idea of hijacking the generic
> term "coroutine" and using it to mean this particular
> type of object.

In my opinion it's OK.  We propose a new dedicated syntax
to define coroutines.  Old approach to use generators to
implement coroutines will, eventually, be obsolete.

That's why, in PEP 492, we call 'async def' functions
"coroutines", and the ones that are defined with generators
"generator-based coroutines".  You can also have
"greenlets-based coroutines" and "stackless coroutines",
but those aren't native Python concepts.

I'm not sure if you can apply term "cofunctions" to
coroutines in PEP 492.  I guess we can call them
"async functions".

>
>> 2. I propose to disallow using of 'for..in' loops,
>>    and builtins like 'list()', 'iter()', 'next()',
>>    'tuple()' etc on coroutines.
>
> PEP 3152 takes care of this automatically from the fact
> that you can't make an ordinary call to a cofunction,
> and cocall combines a call and a yield-from. You have
> to go out of your way to get hold of the underlying
> iterator to use in a for-loop, etc.
>

On the one hand I like your idea to disallow calling
coroutines without a special keyword (await in case of
PEP 492).  It has downsides, but there is some
elegance in it.  On the other hand, I hate the idea
of grammatically requiring parentheses for 'await'
expressions.  That feels non-pytonic to me.

I'd be happy to hear others opinion on this topic.

Thanks!
Yury