I generally like the idea of calling the result of `async def` an "async function", and replacing most uses of "coroutine" in the docs with "async function". The potential confusion with "asynchronous function" (which in my taxonomy is a broader category including both coroutines and functions that take callbacks) is unfortunate, but as long as the syntax is `async def` the term "async function" is almost inevitable and we might as well embrace it.

In Tornado, though, I'm going to keep using the term "coroutine" because our `yield`-based decorated coroutines are important for as long as Python 2 is around. 


On Sun, Oct 9, 2016 at 12:00 PM Guido van Rossum <guido@python.org> wrote:
I'd like input from others, but maybe it's worth expanding the scope

to python-ideas? Not too many people read async-sig. (Or should that

be coroutine-sig? :-)

On Sat, Oct 8, 2016 at 8:50 PM, Nathaniel Smith <njs@pobox.com> wrote:

> On Sat, Oct 8, 2016 at 7:48 PM, Guido van Rossum <guido@python.org> wrote:

>> I've heard people call it an "async def" too.


>> I don't think it's quite as dramatic as you worry about. People also

>> talk about generators (not generator functions) and even though

>> there's a further ambiguity between the function and the type of

>> object it returns, we still get along.


> Hmm, I don't mean to be dramatic. Obviously the world will not end if

> we keep using "coroutine" as the standard term :-). I just think that

> calling them "async functions" (and "async function objects" when the

> distinction is important) would be a nice unambiguous win for pedagogy

> and clarity, and that it's worth grabbing those when you get the

> chance. "coroutine" says more about the history of how we got here

> than about what these things actually mean to a regular end-user;

> "async function" is so transparent that you can skip the vocab

> discussion and go straight to talking about how to use them.


>> There's also the @coroutine decorator.


> There's two of them, even: @types.coroutine and @asyncio.coroutine.

> I'm not really sure what the difference is -- I think at this point we

> could delete some code by making the latter an alias for the former?

> But for now they're still independent and I might be missing

> something.


> And unless I am missing something, these are only useful in rather

> unusual situations: either because you're trying to maintain

> compatibility with 3.4 (which I think will rapidly become irrelevant

> for most asyncio users, if it isn't already) or you're implementing

> your own trampoline (e.g. [1][2]). So even if we leave the decorators

> alone, it doesn't really stop us from switching to clearer terminology

> for day-to-day usage -- most people will never encounter @coroutine

> anyway.


> (For completeness: the other stdlib identifiers I see that mention

> "coroutine" are: sys.{get,set}_coroutine_wrapper, several functions in

> inspect, and asyncio.run_coroutine_threadsafe.)


>> If you have a specific piece of documentation in mind, let's talk --

>> maybe it's fine to change.


> Well, it's a basic concept that gets mentioned constantly throughout

> all discussions... For example, I count 29 instances in [3] and 53

> instances in [4]. Clearly it's useful to have a standard term for

> these things.


> -n


> [1] https://github.com/dabeaz/curio/blob/6166a54a731df59c15fe27791d1c6b048f09f941/curio/traps.py#L46

> [2] https://github.com/njsmith/async_generator/blob/fab4af987cb86c6db549131b66d3ab4c4e327a29/async_generator/impl.py#L13

> [3] https://docs.python.org/3/library/asyncio-stream.html

> [4] https://curio.readthedocs.io/en/latest/reference.html


> --

> Nathaniel J. Smith -- https://vorpus.org


--Guido van Rossum (python.org/~guido)


Async-sig mailing list



Code of Conduct: https://www.python.org/psf/codeofconduct/