[Python-ideas] async/await in Python

[Greg Ewing]

Yury Selivanov wrote:
> I added a section about PEP 3152 to PEP 492:
> https://hg.python.org/peps/rev/428c7c753500
> 
> Please take a look, and feel free to correct me if I
> made any mistakes or forgot to specify something.

 From PEP 492:

> 2. await is defined in almost the same way as yield from in the grammar (it is
> later enforced that await can only be inside async def ). It is possible to
> simply write await future , whereas cocall always requires parentheses. 

The reason for this is to make cocalls grammatically similar
to ordinary calls, so that a cocall can be used in any context
where an ordinary call can be used. This is not the case with
yield-from, which has to be enclosed in parentheses except it
certain special contexts. If I understand your grammar correctly,
"await" has the same characteristics as yield-from in this regard.

> 3. To make asyncio work with PEP 3152 it would be required to modify
> @asyncio.coroutine decorator to wrap all functions in an object with a
> __cocall__ method.

That's not the only way to address this issue. I'll have to think
about it further, but I don't think it would harm anything to have
ordinary generator functions implement __cocall__. Then asyncio
functions, and any other existing generator-based coroutines,
could be used directly in cocalls without requiring any adaptation.

Alternatively, a decorator equivalent to your async_def could be
provided that turns an ordinary generator function into a cofunction.
There would not be any additional overhead involved in calling such
a function.

> 4. Since it is impossible to call a cofunction without a cocall keyword, it
> automatically prevents the common mistake of forgetting to use yield from on
> generator-based coroutines. This proposal addresses this problem with a
> different approach, see Debugging Features . 

This is an important part of the philosophy behind PEP 3152. With
my approach, there is no additional overhead involved in enforcing
it, so there is no need to relegate it to a debugging feature, with
the problems that you point out.

-- 
Greg