GeezerVison

Yeah, I feel the same because the example is a bit artificial. Your example with randomness was probably closer to what people expect in practice, namely tasks that complete in a non-deterministic order and maybe one of them would want to cancel the entire group, but this also means a non-deterministic output (which I don't really want to have in the docs...).

As for playing the devil's advocate for this case, I don't see how we can "badly" use the helper, except if one explicitly changes the CancellableTaskGroup implementation (devil's advocates are welcomed by the way)

Yeah, I feel the same because the example is a bit artificial

I knew it. When I was writing it I was like "hum... it's too long", so I wanted someone else's eyes, so thanks a lot for the comments Guido. I'll address them tomorrow

I kept the output because not everyone wants to run the code (sometimes, they just want to see the output). If you feel that neither the output nor the intermediate printing jobs are needed, please tell me. However, I think it's nice for the users to see a standalone working example.

Maybe it's because I'm not an English native / asyncio expert, but I feel a slight difference with "terminate", "cancel", "stop" and "abort":

• Cancel is kind of generic and can be used to convene the intent of "stopping" whatever is going on. In other words, it can mean "stop", "terminate", "abort" even though it does not use the cancellation in the asyncio sense.

• Stop hints me that I could perhaps resume it later (though you could say it would have been a pause/resume). (A bit like SIGSTOP/SIGCONT).

• Abort hints me that it's something abrupt and "not good". Like "abort the mission" or SIGABRT. It's more for an unexpected event.

I will go for terminate because:

• it terminates/ends/cancels/finishes something,
• it can be thought as SIGTERM which, when emitted, can be caught for a graceful exit (which is the case here, we literally catch the exception), and
• it could be thought as the signal for reaching a "terminal" state where you wouldn't continue (in contrast to "stop").

@willingc I took the liberty of rewording a bit the introductory paragraph. I quite like the While <some-unfortunate-thing>, we can <some-solution> construction.

Thanks @picnixz for the PR, and @gvanrossum for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13.
🐍🍒⛏🤖

GH-123956 is a backport of this pull request to the 3.13 branch.

GH-123957 is a backport of this pull request to the 3.12 branch.

(Presumably the 3.13 backport will be held up by the upcoming release, unless the release manager deems doc PRs harmless. :-)