Greg,
On 2015-04-29 5:12 AM, Greg Ewing wrote:
Guido van Rossum wrote:
On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov
<yselivanov...@gmail.com <mailto:yselivanov...@gmail.com>> wrote:
>
Why StopAsyncIteration?
'''''''''''''''''''''''
I keep wanting to propose to rename this to AsyncStopIteration.
+1, that seems more consistent to me too.
And since PEP 479 is accepted and enabled by default for coroutines,
the following example will have its ``StopIteration`` wrapped into a
``RuntimeError``
I think that's a red herring in relation to the reason
for StopAsyncIteration/AsyncStopIteration being needed.
The real reason is that StopIteration is already being
used to signal returning a value from an async function,
so it can't also be used to signal the end of an async
iteration.
When we start thinking about generator-coroutines (the ones that
combine 'await' and 'async yield'-something), we'll have to somehow
multiplex them to the existing generator object (at least that's
one way to do it). StopIteration is already extremely loaded
with different special meanings.
[..]
Does send() make sense for a native coroutine? Check PEP 380. I think
the only way to access the send() argument is by using ``yield`` but
that's disallowed. Or is this about send() being passed to the
``yield`` that ultimately suspends the chain of coroutines?
That's made me think of something else. Suppose you want
to suspend execution in an 'async def' function -- how do
you do that if 'yield' is not allowed? You may need
something like the suspend() primitive that I was thinking
of adding to PEP 3152.
We do this in asyncio with Futures. We never combine 'yield' and
'yield from' in a @coroutine. We don't need 'suspend()'.
If you need suspend()-like thing in your own framework, implement
an object with an __await__ method and await on it.
No implicit wrapping in Futures
-------------------------------
There is a proposal to add similar mechanism to ECMAScript 7
[2]_. A
key difference is that JavaScript "async functions" always return a
Promise. While this approach has some advantages, it also implies
that
a new Promise object is created on each "async function" invocation.
I don't see how this is different from an 'async def'
function always returning an awaitable object, or a new
awaitable object being created on each 'async def'
function invocation. Sounds pretty much isomorphic to me.
Agree. I'll try to reword that section.
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
