Create new `ASYNC3xx` rules to account for asyncio's different cancellation semantics?

[Zac-HD]

In #211, we noted that ASYNC102 (await-in-finally-or-cancelled) is specific to Trio/AnyIO style "level-triggered" cancellation semantics.

Asyncio has a pretty different system, where cancellation is an event rather than a state (well, mostly - on Python 3.11+ there's also Task.uncancel() to reverse the state change, on 3.10 and earlier you can only partly uncancel).

If someone works out a good lint rule, or set of rules, for asyncio-style cancellation semantics, we'd be happy to accept them as ASYNC3xx rules and make ASYNC102 specific to Trio and AnyIO.

[RomanValov]

Unless ASYNC3xx is implemented is it possible to suppress/ignore ASYNC102 if flake8 is invoked with --asyncio / only asyncio is imported?

[Zac-HD]

I'd be happy to accept a PR for that!

[Dreamsorcerer]

I have a rule proposal, which I'm guessing is going to be specific to asyncio:

Summary

Disallow suppressing a CancelledError in most cases.

i.e.

try:
    ...
except asyncio.CancelledError:
    ...  # Code without an unconditional (re-)raise.

Reasoning

Suppressing cancellations is difficult to get right, and a developer should, at the very least, confirm they've understood the implications and different situations that a cancellation may occur.

A noqa comment can be used by the developer to confirm they've understood this. Alternatively, a couple of safe code patterns may be allowed without needing the noqa. Probably, if there is both an if task.done(): condition and an if asyncio.current_task().cancelling() check in the handler, then the warning is not needed (also, if there is an unconditional raise).

Documentation could link to https://superfastpython.com/asyncio-task-cancellation-best-practices/#Practice_1_Do_Not_Consume_CancelledError for example.

Possibly a separate rule could be to ensure that code which does suppress the exception also calls .uncancel():
https://superfastpython.com/asyncio-cancel-task-cancellation/

[jakkdl]

I have a rule proposal, which I'm guessing is going to be specific to asyncio:

Summary

Disallow suppressing a CancelledError in most cases.

i.e.

try:
    ...
except asyncio.CancelledError:
    ...  # Code without an unconditional (re-)raise.

This is covered by ASYNC103 and applicable to all of anyio/trio/asyncio. But it appears there's a bug in ASYNC103 where it only checks for CancelledError, exceptions.CancelledError, and asyncio.exceptions.CancelledError - but not asyncio.CancelledError.
This is a trivial one-line addition to

flake8-async/flake8_async/visitors/visitor103_104.py

Lines 95 to 99 in aab418e

	elif marker.name in (
	"asyncio.exceptions.CancelledError",
	"exceptions.CancelledError",
	"CancelledError",
	):

+ tests.

PR welcome :)