TaskGroup: tg.cancel() shouldn't block create_task() allow cooperative cancellation

[azibom]

Currently, when a TaskGroup is explicitly cancelled via tg.cancel(), any subsequent call to tg.create_task() raises:

RuntimeError: TaskGroup <TaskGroup cancelling> is shutting down

This contradicts the TODO in the test test_taskgroup_cancel_before_create_task, which states:

This behavior is not ideal. We'd rather have no exception raised, and the child task run until the first await.

Proposed change:
After an explicit tg.cancel() (not after a failure-induced abort), create_task() should succeed. The new task should run its synchronous code up to the first await, then receive CancelledError

For failure-driven aborts (e.g., an exception in another task), the existing RuntimeError is preserved to prevent unsafe task creation during error cleanup.

A PR implementing this change (with a new _explicitly_cancelled flag) is ready and passes all existing tests.

This resolves the TODO and makes TaskGroup behavior more intuitive when voluntarily cancelled.

Linked PRs

• gh-150355: Allow creating tasks in cancelled TaskGroup with cooperative cancellation #150357

[picnixz]

cc @kumaraditya303 Not sure what you want to do about this

[gvanrossum]

@azibom Do you have a better reason for the proposed change than a TODO in a test?

I personally feel that cancelling the task group ought to put the task group into the same state as one of the tasks raising an error -- it should cancel all remaining tasks, and prevent new tasks from being created at the source. (The only difference is that when it's done it doesn't raise, since none of the running tasks raised an error.)

I have no idea where that comment in the test came from. Maybe @belm0 remembers? The checked-in docs actually don't specify, except that the create_task() docs say (and lways said)

If the task group is inactive (e.g. not yet entered,
already finished, or in the process of shutting down),
we will close the given coro.

(It fails to mention that it then raises RuntimeError, but this is als opre-existing.)

The state the task group is in after its .cancel() is called clearly falls under "in the process of shutting down". So I see the current behavior as correct and would rather remove the TODO from that test. (And add to the create_task() docs that it raises RuntimeError in this case.)