On Sat, Oct 8, 2016 at 9:10 PM, Amber "Hawkie" Brown <hawk...@atleastfornow.net> wrote: > >> On 9 Oct. 2016, at 14:50, Nathaniel Smith <n...@pobox.com> wrote: >> >> On Sat, Oct 8, 2016 at 7:48 PM, Guido van Rossum <gu...@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 _______________________________________________ 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/
