nmatravolgyi added the comment:
Closing as duplicate, because there was already an issue for this bug:
https://bugs.python.org/issue42130
--
resolution: -> duplicate
___
Python tracker
<https://bugs.python.org/issu
nmatravolgyi added the comment:
I've also found this deficiency of asyncio.wait_for by debugging an obscure
hang in an application. Back then I've quickly made an issue about it:
https://bugs.python.org/issue43389
I've just closed it as duplicate, since this issue covers t
Change by nmatravolgyi :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue43389>
___
___
Python-bugs-list
nmatravolgyi added the comment:
I did a little research on how the `wait_for` could be improved. There are four
alternate implementations you can find here:
https://github.com/Traktormaster/wait-for2/blob/issue37658/wait_for2/impl.py
The repository (on the linked branch) has tox set-up and
New submission from nmatravolgyi :
I have found myself debugging a *very* not intuitive behavior regarding
asyncio.wait_for that I'd consider a bug/deficiency. The problem very simply
put: wait_for will return the wrapped future's result even when it is being
cancelled, ig
nmatravolgyi added the comment:
I've quickly wanted to create a suitable solution for myself. I made a small
library with a asyncio.wait_for()-like function using asyncio.wait(). The
prototype worked, so I put together a small project. When I ran tox and
realized that this issue
nmatravolgyi added the comment:
One more thing. I've figured out that I can fix the cancellation around the
asyncio.wait_for() with asyncio.shield() like:
try:
await asyncio.shield(wf :=
asyncio.ensure_future(asyncio.wait_for(self.event.wait(), timeout=60.0)))
e