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

[Yury Selivanov]

Paul,

On 2015-04-29 3:19 PM, Paul Moore wrote:
> On 29 April 2015 at 19:42, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>> Here's how it might look like (this is the same pseudo-code
>> but tailored for PEP 492, not a real something)
>>
>>    q = asyncio.Queue(maxsize=100)
>>
>>    async def produce():
>>        # you might want to wrap it all in 'while True'
> I think the "loop" in the Wikipedia pseudocode was intended to be the
> "while True" here, not part of the "while" on the next line.
>
>>        while not q.full():
>>            item = create_item()
>>            await q.put(item)
>>
>>    async def consume():
>>        while not q.empty():
>>            item = await q.get()
>>            process_item(item)
> Thanks for that. That does look pretty OK. One question, though - it
> uses an asyncio Queue. The original code would work just as well with
> a list, or more accurately, something that wasn't designed for async
> use. So the translation isn't completely equivalent. Also, can I run
> the produce/consume just by calling produce()? My impression is that
> with asyncio I need an event loop - which "traditional" coroutines
> don't need. Nevertheless, the details aren't so important, it was only
> a toy example anyway.

Well, yes.  Coroutine is a generic term.  And you can
use PEP 492 coroutines without asyncio, in fact that's
how most tests for the reference implementation is written.

Coroutine objects have .send(), .throw() and .close() methods
(same as generator objects in Python).  You can work with them
without a loop, but loop implementations contain a lot of
logic to implement the actual cooperative execution.

You can use generators as coroutines, and nothing would
prevent you from doing that after PEP 492, moreover, for
some use-cases it might be quite a good decision.  But a
lot of the code -- web frameworks, network applications,
etc will hugely benefit from the proposal, streamlined
syntax and async for/with statements.

[..]
>
> But the use of "coroutine" in PEP 492 for the functions introduced by
> "async def" is confusing - at least to me - because I think of the
> above, and not of async. Why not just call them "async functions" and
> leave the term coroutine for the above flow control construct, which
> is where it originated?
>
> But maybe that ship has long sailed - the term "coroutine" is pretty
> entrenched in the asyncio documentation. If so, then I guess we have
> to live with the consequences.

Everybody is pulling me in a different direction :)
Guido proposed to call them "native coroutines".  Some people
think that "async functions" is a better name.  Greg loves
his "cofunction" term.

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.

Anyways, I'd be OK to start using a new term, if "coroutine" is
confusing.


Thanks,
Yury