Re: [Python-Dev] PEP 492: async/await in Python; v3

Guido van Rossum wrote:

> On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov <ysel...@gmail.com > <mailto:ysel...@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.

>     One of the most frequent mistakes that people make when using>     generators as coroutines is forgetting to use ``yield from``::> >         @asyncio.coroutine>         def useful():>             asyncio.sleep(1) # this will do noting without 'yield from'> > Might be useful to point out that this was the one major advantage of > PEP 3152 -- although it wasn't enough to save that PEP, and in your > response you pointed out that this mistake is not all that common. > Although you seem to disagree with that here ("One of the most frequent > mistakes ...").

I think we need some actual evidence before we can claim
that one of these mistakes is more easily made than the
other.

A priori, I would tend to assume that failing to use
'await' when it's needed would be the more insidious one.
If you mistakenly treat the return value of a function as
a future when it isn't one, you will probably find out
about it pretty quickly even under the old regime,
since most functions don't return iterators.

On the other hand, consider refactoring a function that
was previously not a coroutine so that it now is. All
existing calls to that function now need to be located
and have either 'yield from' or 'await' put in front
of them. There are three possibilities:

1. The return value is not used. The destruction-before-
iterated-over heuristic will catch this (although since
it happens in a destructor, you won't get an exception
that propagates in the usual way).

2. Some operation is immediately performed on the return
value. Most likely this will fail, so you will find out
about the problem promptly and get a stack trace,
although the error message will be somewhat tangentially
related to the cause.

3. The return value is stored away for later use. Some
time later, an operation on it will fail, but it will
no longer be obvious where the mistake was made.

So it's all a bit of a mess, IMO. But maybe it's
good enough. We need data. How often have people been
bitten by this kind of problem, and how much trouble
did it cause them?

> 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.

>     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.

-- 
Greg

_______________________________________________
Python-Dev mailing list
Pyth...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.com