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 <b...@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 <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)
>>
>> _______________________________________________
>>
>> 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)
_______________________________________________
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/
