[Python-Dev] PEP 492: What is the real goal?

Yury Selivanov yselivanov.ml at gmail.com
Tue May 5 18:48:11 CEST 2015

Hi Oscar,

I've updated the PEP with some fixes of the terminology:

I still think that 'coroutine functions' and 'coroutines'
is a better pair than 'async functions' and 'coroutines'.

First, it's similar to existing terminology for generators.
Second, it's less confusing.  With pep492 at some point,
using generators to implement coroutines won't be a wide
spread practice, so 'async def' functions will be the only
language construct that returns them.


On 2015-05-05 12:01 PM, Oscar Benjamin wrote:
> On 30 April 2015 at 09:50, Arnaud Delobelle <arnodel at gmail.com> wrote:
>>> I'm flexible about how we name 'async def' functions.  I like
>>> to call them "coroutines", because that's what they are, and
>>> that's how asyncio calls them.  It's also convenient to use
>>> 'coroutine-object' to explain what is the result of calling
>>> a coroutine.
>> I'd like the object created by an 'async def' statement to be called a
>> 'coroutine function' and the result of calling it to be called a
>> 'coroutine'.
> That would be an improvement over the confusing terminology in the PEP
> atm. The PEP proposes to name the inspect functions
> inspect.iscoroutine() and inspect.iscoroutinefunction(). According to
> the PEP iscoroutine() identifies "coroutine objects" and
> iscoroutinefunction() identifies "coroutine functions" -- a term which
> is not defined in the PEP but presumably means what the PEP calls a
> "coroutine" in the glossary.
> Calling the async def function an "async function" and the object it
> returns a "coroutine" makes for the clearest terminology IMO (provided
> the word coroutine is not also used for anything else). It would help
> to prevent both experienced and new users from confusing the two
> related but necessarily distinct concepts. Clearly distinct
> terminology makes it easier to explain/discuss something if nothing
> else because it saves repeating definitions all the time.
> --
> Oscar

More information about the Python-Dev mailing list