I think I'm convinced by Amber's argument. Coroutines are something you can look up in e.g. Knuth (or Wikipedia) and you'll find something a pretty good match. All queries for "async functions" seem to go to some ECMAScript proposal (similar in nature to PEP 492 actually) and I am not particularly eager to throw ourselves in front of that bandwagon. On Sun, Oct 9, 2016 at 12:34 AM, Ben Darnell <ben@bendarnell.com> wrote:
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.
-Ben
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/6166a54a731df59c15fe27791d1c6b048f09f94...
[2] https://github.com/njsmith/async_generator/blob/fab4af987cb86c6db549131b66d3...
--
Nathaniel J. Smith -- https://vorpus.org
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
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/
-- --Guido van Rossum (python.org/~guido)