Paul,
On 2015-04-29 3:19 PM, Paul Moore wrote:
On 29 April 2015 at 19:42, Yury Selivanov <yselivanov...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
