Zac-HD
commented
1 week ago I'm a little dubious about the value of this rule in addition to #319; it basically amounts to "we think asyncio's cancellation system is too hard to use correctly". Which, yeah, I do; but given that the user hasn't chosen to migrate to anyio I'm not convinced that we're offering a good safety-to-noise ratio.
Can you say more about what we'd be recommending instead, and why that's better (and a better use of developer time than moving to anyio)?
https://docs.python.org/3/library/asyncio-task.html#asyncio.shield has the double footgun of #319 and having to reroute the shielded task to a different context where it can be properly monitored for completion of errors. If you're already doing the latter, you might as well send the coroutine directly and you will have fewer problems handling the Task/Future. Inspired by @graingert
Implementation would be trivial, most of the work would be writing documentation that explains the issue and how to resolve it.