[Python-ideas] async/await in Python

[Andrew Barnert]

On Sunday, April 19, 2015 7:02 AM, Steven D'Aprano <steve at pearwood.info> wrote:

> > On Sat, Apr 18, 2015 at 09:55:45PM -0700, Andrew Barnert wrote:
> 
>>  > 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.
> 
> -1 on "new-style". New-style classes have been around since Python 2.3 
> 
> in 2003, which is twelve years ago. In what way are they still "new"?
> 
> At least with new-style classes, the plan always was to deprecate 
> classic classes, and in Python 3 the distinction is gone and "type" 
> and 
> "class" are, at least, synonyms. But here I understand that the 
> generator-based coroutines and the async-def syntax coroutines will 
> coexist forever.

Read the message I was replying to:

> 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).

So, while building coroutines out of generators may never be deprecated, they intention is that in practice they do _not_ coexist forever.

Yuri did back off the "quite soon" wording he used earlier, acknowledging that code will probably need to maintain backward compat with 3.4 for a while--which is why the naming confusion is, at least in the short term, a problem (or so it seems to me).

If you think that intention is either impossible or undesirable, that's a different story (and it might affect some of the other decisions that went into the PEP…).

> When Python is 40+ years old, will anyone care that 
> generator-based coroutines were added a few releases before async-def 
> coroutines?

If they're both being used side-by-side, sure. But again, that's not the intention by the time Python is 40 years old. If the only reason anyone has to learn about generator-based coroutines is to work on code from around 2015, at which point they have to learn that this is how we did things before we had syntactic support, then yes, the fact that they are "old-style" is clearly relevant.

(Of course there will always be a couple of people who like playing with language features for its own sake who will either dig up Greg Ewing's posts that led to the asyncio design, or rediscover the idea that you could build coroutines out of generators for themselves. But those kind of people, we don't have to worry about confusing…)

>>  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).
> 
> That doesn't apply here. New-style classes and classic classes are 
> *almost* the same. The differences are subtle. But the differences 
> between generator-based and async-def coroutines are quite considerable. 

But none of those differences are relevant to someone who's never used the generator-based coroutines, never learned them, and will likely never need to.


Also, notice that people using 2.7 can very easily accidentally create classic classes and then run into bugs; nobody using 4.6 will accidentally create a generator-based coroutine. People using 2.7 still have to use classic classes to work with major frameworks like the stdlib's Tkinter; that's unlikely to be true in 4.6. And, unlike classic classes, which were a fundamental part of Python for something like 6 years, generator-based coroutines will end up being a footnote if they were only used in one provisional framework for one major version.

> Let's see if I have them all...
> 
> Generator-based:
> - must use `yield` as an expression;
> - cannot use `await`; (?)
> - must be declared with a plain `def`;
> - must be primed before use;
> - use the send() method;
> 
> Async-def:
> - must not use `yield` or `yield from`;
> - may use `await`; (?)
> - must be declared with `async def`;
> - don't need priming;
> - the send() method isn't used; (?)
> 
> Apart from the underlying technology, they are nothing alike.

Well, if they really are nothing alike, we shouldn't call them both coroutines.

But I don't think that's true. What they're used for, and how they work, are fundamentally the same; just the details are different. They are both coroutines; there's the new, clean way to do coroutines, and the old way that still works but you don't want to use it, and if you do need to use it you'll have to learn all the details.

> Earlier, with my tongue planted firmly in my cheek, I suggested 
> "pyroutines" as a pun on "goroutines" (which is of course a 
> pun on 
> coroutines).

Greg Ewing's pointed out that the proposal is almost equivalent to PEP 3152 except for the naming; his PEP used "cofunction" and related terms instead of "coroutine", which definitely solves the problem.

But I think it may be too drastic a solution. Especially since the same style of await-driven async programming is used in other major languages, and referred to in terms of coroutines. If we have to explain that "Yes, Python has coroutines just like C#, but we call them cofunctions, and we have these other things that are similar but different and not compatible that we call coroutines", I think the proposal loses a lot of its appeal. If it's necessary, it's necessary, but we shouldn't do it unless it really is.

> Silly as that was, I'd rather it than enshrine 
> "new-style" 
> and "old-style" again.