[issue25887] awaiting on coroutine more than once should be an error

Changes by Yury Selivanov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue25887] awaiting on coroutine more than once should be an error

Roundup Robot added the comment: New changeset c2a2685ab89b by Yury Selivanov in branch '3.5': Issue #25887: Raise a RuntimeError when a coroutine is awaited more than once. https://hg.python.org/cpython/rev/c2a2685ab89b New changeset 23297d5bbd29 by Yury Selivanov in branch 'default': Merge 3.5

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: > After thinking about this some more, I think my problem with asyncio.wait() > is a bit bigger than the simple fact that coroutine objects cannot be awaited > multiple times. It seems to me like asyncio.wait() is completely broken for > coroutine objects as

[issue25887] awaiting on coroutine more than once should be an error

André Caron added the comment: After thinking about this some more, I think my problem with asyncio.wait() is a bit bigger than the simple fact that coroutine objects cannot be awaited multiple times. It seems to me like asyncio.wait() is completely broken for coroutine objects as inputs and

[issue25887] awaiting on coroutine more than once should be an error

André Caron added the comment: > I believe you're not using the asyncio.task() function correctly. I assume you meant asyncio.wait(). I just updated my gist with a variant of my example that uses the (done, pending) pair returned by asyncio.wait() as you suggested. The set of done futures tha

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: > I haven't looked at the patch, but the intent to make the 2nd > await raise a RuntimeError seems strange for several reasons: > - it's inconsistent with the Future/Task interface; Well, coroutines are much more lower level than Future/Tasks. > - it's quite

[issue25887] awaiting on coroutine more than once should be an error

André Caron added the comment: Hi there! I've just stumbled upon this behavior and I was also surprised by the fact that the second await simply returns None. After fiddling around for a while, I noticed that if I wrap the coroutine object using asyncio.ensure_future() or asyncio.get_event_lo

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: >"Cannot reuse already awaited coroutine" Great, I like it! Thanks Martin and Nick. Please check out issue #25888 just in case. -- ___ Python tracker ___

[issue25887] awaiting on coroutine more than once should be an error

Nick Coghlan added the comment: I expect whatever message we use will become a Stack Overflow question in fairly short order, so "good enough" is almost certainly good enough here, and I'm massively overthinking the problem :) However, combining my last suggestion with a variant of Martin's wo

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: Oh, choosing a good error message is hard :( I've a few comments. Sorry, this thread is growing rather rapidly, but please help me to pick one of them: > From the point of view of the error message, the reason I changed my > suggestion was because I liked y

[issue25887] awaiting on coroutine more than once should be an error

Martin Panter added the comment: Isn’t the combined point of this issue and Issue 25888 to make it only legal to “await” a coroutine instance that has not yet been started? Perhaps “Cannot [re]start terminated coroutine” would be better. -- ___ Pyth

[issue25887] awaiting on coroutine more than once should be an error

Nick Coghlan added the comment: Sorry, dropping the "was" was a typo (I should have copied & pasted it instead of rewriting). >From the point of view of the error message, the reason I changed my >suggestion was because I liked your idea of optimising it for the "only using >await" case and t

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: "Cannot await previously awaited coroutine" might be confusing if raised on "coro.send(..)"-like code... So far "coroutine was already awaited on" (do you want to drop "was", btw?) is less of all evil IMHO. -- ___

[issue25887] awaiting on coroutine more than once should be an error

Nick Coghlan added the comment: Good point about having "await" in the error message to make it more obvious what it's referring to in the "awaiting twice" case. I'll tender "Cannot await previously awaited coroutine" as one final alternative, but if you don't like that, I can cope with "Corou

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: > IMO “yield from coroutine_iterator” might be plausable for some strange > combination of 3.4 code and a 3.5 coroutine, but I think it would be rare. > And if you added a check in __await__() then the using “await” wouldn’t need > to rely on next() raising th

[issue25887] awaiting on coroutine more than once should be an error

Martin Panter added the comment: If the coroutine-iterator is going to raise RuntimeError rather than StopIteration, do you think the __await__() documentation should be clarified? IMO “yield from coroutine_iterator” migh

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: Attaching an updated patch. The RuntimeError says 'coroutine was already awaited on' for now. -- Added file: http://bugs.python.org/file41588/Issue25887_4.patch ___ Python tracker

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: Nick, > After all, waiting for the result with "await" is only one way to terminate a > coroutine - you can also get there with direct calls to next(), send(), > throw() and close(). Yes, but I expect that almost nobody will use 'send', 'throw' etc on corout

[issue25887] awaiting on coroutine more than once should be an error

Martin Panter added the comment: The patch looks like it adds checks for the special generator-like send() etc methods, but I was expecting __await__() to also (or instead) do this check. That way you wouldn’t have to break the iterator protocol by the iterator not raising StopIteration a seco

[issue25887] awaiting on coroutine more than once should be an error

Nick Coghlan added the comment: The patch looks good to me, but I'd like to see the error message convey two points: - the coroutine has already terminated (regardless of how that happened) - the calling code attempted to resume it anyway That is, something like "Cannot resume terminated corout

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: > I don't like "coroutine was already awaited". I feel like either "on" should > be appended to that or another sentence like "coroutine had 'await' called on > it" or something. Fine with me to have "coroutine was already awaited on". -- ___

[issue25887] awaiting on coroutine more than once should be an error

Brett Cannon added the comment: I don't like "coroutine was already awaited". I feel like either "on" should be appended to that or another sentence like "coroutine had 'await' called on it" or something. -- ___ Python tracker

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: Attaching another patch. Please review (I plan to commit it tomorrow in 3.5 and 3.6 branches). The patch affects generators machinery in the following way: 1. Generators behaviour isn't touched, the patch is only for 'async def' coroutines. 2. Calling 'send

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: New patch -- added more tests, made gen_send_ex() to always raise an error if the genobject is an exhausted coroutine. -- Added file: http://bugs.python.org/file41337/Issue25887_2.patch ___ Python tracker

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: Please review the attached patch. -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file41336/Issue25887.patch ___ Python tracker _

[issue25887] awaiting on coroutine more than once should be an error

Changes by Brett Cannon : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue25887] awaiting on coroutine more than once should be an error

Guido van Rossum added the comment: PEP 492 is provisional, we can change things like this in 3.5.2. On Wed, Dec 16, 2015 at 3:48 PM, Martin Panter wrote: > > Martin Panter added the comment: > > It should always be valid to create a new coroutine instance. Perhaps you > meant: > > instance =

[issue25887] awaiting on coroutine more than once should be an error

Yury Selivanov added the comment: > OK, but only for await (not for yield from). Sure, generators will stay untouched (I'll even add a unittest for that, if we don't have it). > It should always be valid to create a new coroutine instance. Perhaps you > meant: Correct, Martin, great that yo

[issue25887] awaiting on coroutine more than once should be an error

Martin Panter added the comment: It should always be valid to create a new coroutine instance. Perhaps you meant: instance = foo() print(await instance) # Okay the first time print(await instance) # Second time should be an error This seems sensible, at least for 3.6. Maybe it should also be

[issue25887] awaiting on coroutine more than once should be an error

Guido van Rossum added the comment: OK, but only for await (not for yield from). -- ___ Python tracker ___ ___ Python-bugs-list mailin

[issue25887] awaiting on coroutine more than once should be an error

New submission from Yury Selivanov: async def foo(): return 123 print(await foo()) # will print 123 print(await foo()) # prints None print(await foo()) # prints None The above code illustrates the current behaviour. I propose to change it, so that second 'await' will trigger a Runt