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