Repository navigation
Rewrite asyncio.wait_for using asyncio.timeout #96764
Description
Over the years a lot of issues have accumulated for asyncio.wait_for and the code has become complicated. The asyncio.timeout can be used to simplify this a lot and will also fix bugs which are already fixed or don't exist in asyncio.timeout. This rewrite won't be backported. asyncio.wait_for should be nothing more than a wrapper around asyncio.timeout.
asyncio.wait_for issues: https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+wait_for+label%3Aexpert-asyncio
Linked PRs
Metadata
Metadata
Assignees
Projects
- Status
Activity
gvanrossum commentedon Sep 12, 2022
Note that whatever we do should preserve all the existing behavior in
wait_for(). Breaking existing code using it would be worse than keeping a bunch of issues that people can avoid by switching to usingtimeout()directly.kumaraditya303 commentedon Sep 17, 2022
@graingert IIRC you had a branch for this, interested in this?
graingert commentedon Sep 17, 2022
Yeah I'm interested, but one thing to note is that wait_for has changed dramatically between versions so matching the behavior is hard
kumaraditya303 commentedon Sep 17, 2022
It can be evaluated by checking how many tests it breaks by just changing it to use
asyncio.timeoutand take it from there.graingert commentedon Sep 17, 2022
#31847 (comment) here's the work so far
GH-96764: rewrite `asyncio.wait_for` to use `asyncio.timeout` (#98518)
eIGato commentedon Mar 14, 2023
When can we expect it to be released?
And under what patch number?
gvanrossum commentedon Mar 14, 2023
3.12
cretz commentedon Nov 9, 2023
Just want to note on this issue that this change is an unfortunate compatibility break in our Temporal deterministic event loop implementation. We can deterministically implement
call_laterbecause it's relative time, but nowwait_foruses fixed time ofcall_atwhich our time-travelling event loop can't support. I am looking into options...