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
_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/