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.ml at gmail.com <mailto:yselivanov.ml at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4