So this needs to be reviewed carefully by@agronholm and@Tinche -- not so much regarding "code review" but regarding "does this address our concerns, does it fix the edge cases, can we implement Trio-like behavior in 3rd party libraries when we need it". I'd also like@cjerdonek to think about this.

We also, separately, need to debate whether the lines

ifself._num_cancels_requested>1:returnFalse

should stay in or not. IIRC@agronholm has claimed that this (or the previous incarnation) broke several AnyIO tests.

There are two aspects that would change if we removed these two lines:

1. The cancel message. Seehttps://bugs.python.org/issue46829. In 3.10, aftert.cancel("first"); t.cancel("2nd") the cancel message ended up being set to"2nd"; with 3.11 main it ends up"first". If we remove these two lines it would become"2nd" again.
2. How many CancelledError exceptions will the task see? In 3.10, the taskmay see multiple cancellations -- but it may not. In particular, if the second cancel() call finds the must-cancel flag already set, only one cancellation will be delivered. However, if the first cancellation is delivered, and the task catches the CancelledError and then usesawait to do some cleanup, in 3.10 (and again if we remove those two lines) that cleanupawait will be cancelled; but if we keep those two lines, thatawait will be shielded.

Great! Let me take another look if any of the method comments need rewrites.

As forcancelling(), while thinking about this PR I came to the same conclusion as you folks (that it's not needed) but I left it in. In the process I rewrote the TaskGroup very slightly to not use it (and potentially cancel its children only once). We're leavingcancelling(), but would this TaskGroup patch also be interesting?

Yes, I am very much interested in your TaskGroup PR. There are a couple of things there that could be improved:

• It doesn't always preserve the cancel message (since it doespropagate_cancellation_error = et instead ofpropagate_cancellation_error = exc -- I don't know why not, could be a carry-over from the pre-3.9 days when it didn't matter).
• There's weirdness aroundself._base_error. It seems that if__aexit__() receives a CancelledError (which is a base error) then that will always be raised (L124) before we get toraise propagate_cancellation_error (L130)?
• We could, if we wanted, distinguish between a child task being cancelled by TaskGroup._abort()` and it being cancelled for some other reason. Currently, if it's the latter, the CancellationError from the child task is swallowed and treated as if it exited successfully.

There's also some weirdness aroundself._on_completed_fut. It is set to None twice (once in the while loop and once after the loop has finished). But this is not related to cancellation (and the issue is benign).

@Tinche I forgot to mention: I'm waiting for you before I land it. If you don't mind I'd rather see the TaskGroup changes in a separate PR (since this PR is complete as-is and the TaskGroup improvements should probably be tagged withbpo-46752).

@gvanrossum Roger, task group will be a different PR. I tweaked the docstrings, please merge if it's good.

Oh, you have to re-run clinic (make clinic) and commit and push the resulting changes. (Done)

Congrats@Tinche on your first merged Python PR! Thanks for your patience. I hope this will ease the pain for Quattro.

Thank you kindly. I will get started on a TaskGroup PR soon.