[Async-sig] A modest terminological proposal

[Thomas Nyberg]

This is in reply to this message in the archives:

     https://mail.python.org/pipermail/async-sig/2016-October/000141.html

Nathaniel Smith:
 > I've found that when talking about async/await stuff recently, I've
 > mostly dropped the word "coroutine" from my vocabulary and replaced it
 > with "async function". I'm writing to suggest that we might want > to
 > make this switch as a community, and do it now, before the next 10x
 > increase in the async/await userbase.

For what it's worth, I 100% agree.

 > *Accuracy*: Speaking of jargon, the term "coroutine" *is* an existing
 > piece of jargon in computer science, and our term and their term don't
 > quite match up. This isn't a huge deal, but it's unnecessary
 > confusion.  According to Wikipedia I guess technically we don't even
 > have "true" coroutines, just "semicoroutines"? And every generator has
 > just as much claim to being a coroutine-in-the-CS-sense as an async
 > function does, but when we say coroutine we don't mean generators.
 > (Except when we do.) This confusion might partly reflect the somewhat
 > confusing transition from 'yield from' to async/await, as demonstrated
 > by the official doc's somewhat confusing definition of "coroutine":

I've personally been very confused lately by python's terminology. I've
always understood coroutines to have nothing a priori to do with event
loops, scheduling. For example, I've understood coroutines as being
objects that allow the following kind of flow (taken from
https://en.wikipedia.org/wiki/Coroutine#Comparison_with_subroutines):

      var q := new queue

      coroutine produce
          loop
              while q is not full
                  create some new items
                  add the items to q
              yield to consume

      coroutine consume
          loop
              while q is not empty
                  remove some items from q
                  use the items
              yield to produce

Python has basically supported this flow since 2.x (apart from the
terminology issue of semi-coroutines mentioned above which I feel is
relatively minor).

This big point though is that being scheduled or asyncronous is kind of
a separate property. Posix threads are implemented by feeding it a
routine to start things off just like much of python's asyncronous stuff
is built around coroutines, but I don't feel like the term "coroutines"
should be merged into both just as routines aren't automatically tied to
threads.

Personally I think if anything the best possible comparison else where
in computer science are the haskell thunks which delay execution until
needed.  That's the first thing I think about when I see how curio is
setup for example.

I recognize that it is very unlikely that this will change (hey language
meaning changes over time), but I felt like I should reply after finding
this thread because I personally have been very confused by the
terminology used by python. (Personally I've been using coroutines by my
definition for years using yield/send.)

Thanks a lot for the write-up though. You saved my sanity a little
bit...

Cheers,
Thomas