[Python-ideas] async/await in Python

[Andrew Barnert]

On Apr 18, 2015, at 19:27, Andrew Barnert <abarnert at yahoo.com.dmarc.invalid> wrote:
> 
>> On Apr 18, 2015, at 10:39, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>> 
>> Hi Steven,
>> 
>>> On 2015-04-18 1:11 PM, Steven D'Aprano wrote:
>>> Nicely written and very complete! I only have a couple of little
>>> niggles, which some might consider bike-shedding. See below.
>> 
>> Thanks a lot!
>> 
>>> 
>>> 
>>> On Fri, Apr 17, 2015 at 02:58:58PM -0400, Yury Selivanov wrote:
>>> 
>>> [...]
>>>> From this point in this document we use the word *coroutine* to refer to
>>>> functions declared using the new syntax.  *generator-based coroutine* is
>>>> used where necessary to refer to coroutines that are based on
>>>> generator syntax.
>>> It concerns me that we will have two kinds of coroutines.
>>> 
>>> At the moment, we have two kinds of generator functions: those that are
>>> used as generators, and those that are used as coroutines, depending on
>>> whether they contain "yield expr" or "x = (yield expr)". That
>>> distinction won't go away, but now we will have even more ambiguity of
>>> language: there will be generators which are functions:
>>> 
>>>    def gen(): yield 1
>>> 
>>> generators which are not functions but the result of calling a generator
>>> function:
>>> 
>>>    g = gen()
>>> 
>>> coroutines which are generators:
>>> 
>>>    def gen():
>>>        x = (yield 1)
>>>        y = (yield x+1)
>>> 
>>>    cr = gen()
>>> 
>>> and coroutines which are not generators:
>>> 
>>>    async def g():
>>>        await spam()
>>> 
>>> Except that they will be implemented internally as generators. There
>>> will be generators that use yield and generators which give a syntax
>>> error with yield. My head hurts :-)
>>> 
>>> I think it will be hard to unambiguously talk about these things without
>>> confusion, especially for people with limited asyncronous experience.
>>> 
>>> I don't have an answer to this, but I know that even the generator
>>> versus generator-function ambiguity (both get called "generator")
>>> sometimes leads to confusion. (E.g. below you talk about passing a
>>> generator to types.async_def but it isn't clear to me whether you mean
>>> the generator or the generator function.) There's been at least one
>>> thread on python-list in the last few months about that. Is it possible
>>> to use another name to distinguish generator-based coroutines from
>>> async-based coroutines?
>>> 
>>> It's a pity we can't steal the name "goroutine" from Go. I've always
>>> liked that name :-) but as I understand it, goroutines completely
>>> unrelated to coroutines. Hmmm... maybe we could use pyroutines? *wink*
>>> 
>>> If the name must stay as-is, it would help to have an unambigous and
>>> clear summary of the various generator-or-coroutine uses and how they
>>> differ.
>> 
>> The PEP kind of addresses this, but calling current approach
>> to do coroutines "generator-based coroutines", and the new
>> ones as just "coroutines".
> 
> The only problem is that, when it's important to specify that you mean the new kind of coroutines explicitly, there's no obvious way to do so--if I say "async coroutines" someone may reasonably think I'm referring to "coroutines as user in asyncio".

Actually, to answer my question: I could just say "new-style coroutine".

When I say "new-style class", novices aren't confused by that, and they get the idea that these are probably the kind of class they want; experts have already learned what it means; people in between can look it up easily enough if it's relevant.

And of course it's obvious how to shorten "new-style class" when the difference isn't relevant to the discussion: you just say "class" (maybe with an asterisk saying "new-style, of course", but usually without even needing that).

So, the same thing would probably work here.

> I could say "PEP XXX coroutines" or "awaitable coroutines" or "non-yield-from coroutines" or probably various other things, but none of them are the first thing that comes to mind.
> 
> It definitely seems plausible that eventually the ambiguity will vanish, as nobody will talk about the other kind of coroutines except as an implementation detail for backporting code to 3.3/3.4 (which will itself probably not be common for that long) or porting the feature itself to other implementations. 
> 
> But it might be nice to have an official name that can be used when necessary until that happens. (I don't know what that name should be.)
> 
>> The internal implementation based on generators is something
>> that was absolutely required to cover in the PEP in a great detail,
>> but almost everybody will forget about that fact pretty soon.
>> 
>> The point of this PEP is to actually avoid any confusion, and
>> to just have two separate concepts: coroutines and generators
>> (the latter can still be used as a "coroutine-like" object,
>> but hopefully nobody will do that at some point).
>> 
>>> 
>>> 
>>>> types.async_def()
>>>> -----------------
>>>> 
>>>> A new function ``async_def(gen)`` is added to the ``types`` module. It
>>>> applies ``CO_ASYNC`` flag to the passed generator's code object, so that it
>>>> returns a *coroutine object* when called.
>>>> 
>>>> This feature enables an easy upgrade path for existing libraries.
>>> When you say "the passed generator", do you mean the generator function or the generator object?
>>> E.g. given:
>>> 
>>> def gen():
>>>    yield 1
>>> 
>>> which do I use? async_def(gen()) or async_def(gen)?
>> 
>> It's generator-function.  It's a very good catch.
>> 
>> I've updated the PEP.
>> 
>> 
>> Thanks!
>> Yury
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/