I figured I'd throw it out here for initial feedback on the theory that it'd be higher signal to noise, and then proceed to python-ideas if the async aficionados seemed generally in favor.
On Sat, Oct 8, 2016 at 8:59 PM, Guido van Rossum <gu...@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 <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. >> >>> 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 > > > > -- > --Guido van Rossum (python.org/~guido) -- 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/