[Python-ideas] async/await in Python

[Yury Selivanov]

Hi Greg,

On 2015-04-17 8:21 PM, Greg Ewing wrote:
> Yury Selivanov wrote:
>>
>> Here's my proposal to add async/await in Python.
>
> You've essentially reinvented PEP 3152 - Cofunctions.
>
> https://www.python.org/dev/peps/pep-3152/
>
> Here's a summary of the relationships between them:
>
> PEP 3152                  Nearest equivalent in Yury's PEP
> --------                  --------------------------------
>
> codef f(args):            async def f(args):
>
> cocall f(args)            await f(args)
>
> __cocall__                __await__
>
> costart()                 async_def()

Let me list the key differences here:


1. Keywords, that's obvious. To be honest, I don't like
cocall, codef, cofor, and cowith.  That's my personal,
highly subjective, opinion, though.


2. I don't like the special relationship of 'cocall' token
and parens in the grammar.

What's going on here: 'cocall foo()()'? And what's
'cocall foo().bar()'?  Will it raise a SyntaxError in the
former case?  And in the latter -- are you cocalling
'foo().bar' or 'foo()'?  These are rhetorical questions,
but in real life people will ask them.


3. 'costart' is not an equivalent of 'async_def'.

'async_def' allows you to wrap existing generator-based
coroutines into the proposed 'async def' ones.

By using 'async_def' in asyncio.coroutine decorator
we can seamlessly enable all existing asyncio code
to be used in 'await' expression.

I don't see how you can do this with costart().

Probably you need some kind of a wrapper object, like that:

class CoCoro:
    def __cocall__(self, *args, **kwargs):
        return (yield from self.__wrapped__)

and apply it to all asyncio coroutines.

That's some extra tax right here.  While 'async_def' is
simply flipping a CO_ASYNC bit.


4. Lack of 'async with' and 'async for', obvious again.


>
> There is currently no equivalent of "async for" and
> "async with" in PEP 3152, but they could easily be added.
> I would probably spell them "cofor" and "cowith".
>
> As the author of PEP 3152 I'm obviously biased, but I
> think my spellings are more elegant and less disruptive
> to reading of the code.
>
> PEP 3152 is currently marked as deferred. Maybe it's
> time to revive it? If Yury's pep is to be considered,
> we ought to discuss the relative merits of the two.
>

Thank you,
Yury