Both Yury's suggestions sounds reasonable. On Tue, Dec 15, 2015 at 10:24 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote: > Hi Roy and Guido, > > On 2015-12-15 3:08 PM, Guido van Rossum wrote: > [..] >> >> >> I don't know how long you have been using async/await, but I wonder if >> it's possible that you just haven't gotten used to the typical usage >> patterns? In particular, your claim "anything that takes an `awaitable` has >> to know that it wasn't already awaited" makes me sound that you're just >> using it in an atypical way (perhaps because your model is based on other >> languages). In typical asyncio code, one does not usually take an awaitable, >> wait for it, and then return it -- one either awaits it and then extracts >> the result, or one returns it without awaiting it. > > > I agree. Holding a return value just so that coroutine can return it again > seems wrong to me. > > However, since coroutines are now a separate type (although they share a lot > of code with generators internally), maybe we can change them to throw an > error when they are awaited on more than one time? > > That should be better than letting them return `None`: > > coro = coroutine() > await coro > await coro # <- will raise RuntimeError > > > I'd also add a check that the coroutine isn't being awaited by more than one > coroutine simultaneously (another, completely different issue, more on which > here: https://github.com/python/asyncio/issues/288). This was fixed in > asyncio in debug mode, but ideally, we should fix this in the interpreter > core. > > Yury > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov
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