[Async-sig] A modest terminological proposal

[Amber "Hawkie" Brown]

> On 9 Oct. 2016, at 14:50, Nathaniel Smith <njs at pobox.com> wrote:
> 
> On Sat, Oct 8, 2016 at 7:48 PM, Guido van Rossum <guido at 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.

I am of the reverse opinion -- they should be called coroutines, not asynchronous functions.  Calling them "async functions" implies that they are asynchronous; they are actually completely synchronous constructs built of potentially asynchronous code and used in larger asynchronous systems. A coroutine, by itself, is not asynchronous. But I guess it's 'async def' and not 'coro def'... :)

As an example of the consequences of naming, there have been several cases where asyncio users of Autobahn have attempted to do large file I/O, and thought that because they were using 'asyncio' it would be fine, and have ended up blocking the event loop because of it. There's no such thing as asynchronous file system access, which is one of the most basic kinds of I/O, which has lead to this impression.

- Amber