[Python-ideas] async/await in Python

[David Wilson]

On Fri, Apr 17, 2015 at 02:58:58PM -0400, Yury Selivanov wrote:

> I believe that PEPs 380 and 3156 were a major breakthrough for Python
> 3, and I hope that this PEP can be another big step.  Who knows, maybe
> it will be one of the reasons to drive people's interest towards
> Python 3.

An offer like this would assuredly and irrevocably propel me from my
"Python 3 conservative" position and well into the "Python 3 zealot"
stratosphere :)

A great deal of thought has obviously gone into your proposal, so I
expect you already have answers to these:


    Regarding introduction of async/await keywords, could e.g. the
tokenizer change be avoided by moving the 'async' keyword after the
parameter list? like "def foo(x) async:". That would seem parseable
without introducing any new token, since the parser could be made to
error out if any identifier except "async" appears, similarly instead of
introducing an 'await' keyword, 'yield await' might be possible. (Please
forgive me if my parsing ignorance is showing through)


    Further regarding the introduction of the await keyword, within an
async function did you consider the possibility of making suspension of
the coroutine implicit?

>From the perspective of the interpreter, objects exposing __await__
might grow a .tp_await slot which could trivially be tested for NULL
during e.g. the CALL_FUNCTION opcode epilog, though I guess this stuff
strays quite far from well understod async/await designs from other
languages (e.g. C#).

I quite like the idea of folding the mechanism out of the user's sight
as far as practical, though I don't know if that's possible without
introducing ambiguities.


    Is there a need or desire for "async lambda ...:"? Notably, it's
possible though fairly useless to define a lambda generator:
"lambda x: (yield from x)" works today.


    Generally the magic to avoid backwards compatibility issues seem
less desirable than simply including a new __future__ mode, though the
stated reasons for the trickery are good. Somewhat contradicting my last
point, __future__ serves as very useful documentation for a file's
implementation.

Regarding the problematic module import example, that might easily be
solved by simple file rename and introducing a stub module for old code
like:

    async_impl.py:
        # Guts of old async.py

    async.py:
        from .async_impl import *  # NOQA

Similarly for object attributes and suchlike, properties might suffice.

Thanks for proposing this! Off to buypopcorn, very much looking forward
to seeing how the thread plays out. ;)


David