bpo-33413: asyncio.gather without a special Future #6694
Conversation
if a gather whose futures are already all done, but didn't get the chance to return yet gets cancelled, it still has to propagate that cancellation up the task chain. In the past the test tests a proxy to that, some behavior of a _GatheringFuture that will lead to this propagation. This test now tests the real thing: we test that the cancellation is propagated.
in the past, a special _GatheringFuture inherited from Future. This is very archaic. Now we simply use a Task.
gather now needs an event loop round more to work, just give it that time.
|
This PR is stale because it has been open for 30 days with no activity. |
|
@serhiy-storchaka Could you review this? |
github-actions
bot
removed
the
stale
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
|
@tecki are you still interested in pushing this forward? The PR is over 4 years old and the merge conflict seems pretty serious -- your best approach may be to start over from scratch. |
|
Hi @tecki, Thanks for opening this PR. I'm going to go ahead and close this PR. Should you wish to work on this issue in the future, please open a new PR. Thank you. ☀️ |
This re-implements asyncio.gather without the need of a special inherited Future.
Futures nowadays are created using loop.create_future(), so having a special-case Future is actually weird. This changes gather() to simply return a Task.
This patch goes at great length to stay backwards compatible. It splits the function gather() in two parts: a backwards-compatible gather() that wraps the coroutine _gather() into an ensure_future(). IMHO the _gather() is everything one would need.
https://bugs.python.org/issue33413