[Async-sig] A modest terminological proposal

[Nathaniel Smith]

On Sat, Oct 8, 2016 at 9:10 PM, Amber "Hawkie" Brown
<hawkowl at atleastfornow.net> wrote:
>
>> 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.

Small but meaningful nitpick: the proposal is to call them "async
functions", not "asynchronous functions". It's named after the "async"
keyword. Any resemblance of that keyword to an English word is ... a
separate problem :-).

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

Oh yeah, communicating this is definitely a huge challenge. But I feel
like as long as the keyword is 'async' and the words "async" or
"asynchronous" are on the book covers and the for loops and generally
attached to every single thing except for the
documentation-term-for-the-function-like-thingummies, then this
confusion is going to happen and we're going to have to do the work to
explain what we mean when we say 'async'. Throwing in "coroutine" as
an extra piece of opaque jargon doesn't really help this, IMO. And if
we have to explain what 'async' means anyway, then 'async function'
comes along for free. (Of course if teaching someone about this stuff
I still have the *option* of explaining what coroutines are and how
async functions are an example of the concept, if I think that well
help -- just now it's my decision whether I want to go there or not
:-).)

-n

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