Caleb Hattingh <caleb.hatti...@gmail.com> added the comment:
> asyncio.wait_for is still confusing Perhaps the confusion can be fixed with improvements to the docs? To me, these specific docs seem pretty clear now, but I might not be a good judge of that. > However, we still have the case where a misbehaving Task can cause wait_for > to hang indefinitely. The key word here is "misbehaving". Cooperative concurrency does require cooperation. There are many ways in which coroutines can misbehave, the popular one being calling blocking functions when they shouldn't. I would be very uncomfortable with my coroutine being killable (e.g. by wait_for) by some other means besides CancelledError (which I can intercept and manage cleanup). The contract is: if my coroutine has a CancelledError raised, I take that to mean that I need to clean up whatever resources need cleanup, in a timely manner and then exit. If my coro refuses to exit, it is my coroutine that is wrong, not wait_for being unable to kill the coroutine. I definitely agree with Yury that the previous behaviour, the one where wait_for could raise TimeoutError *before* the inner coro has exited, was buggy and needed to be fixed. ---------- nosy: +cjrh _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37736> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
