These docs make sense for older versions.

Probably recommending a backport module on PyPI would be better

These docs were just added in September, and backported to 3.13 and 3.12.

It's my understanding that the deletion here wouldn't affect the docs of previous versions.

As for this PR, I'd expected it to be backported as far back as is allowed by policy.

@belm0 are you interested in applying this change and any previous changes to my taskgroup backport?

This is new API, so we won't backport it.

I'm talking about backporting to pypi

Ah, sure. PyPI is off limits :)

Maybe these tasks should look like this?

asyncdeftask(results,num):results.append(num)awaitasyncio.sleep(math.inf)results.append(-num)

So we can assert what was inresults

For this particular test, I chose a different test approach, which is to wrap inasyncio.timeout().

For the other tests usingcount, I'm not sure it's much value, since the test code is only a few lines and there is only one possible path through it. Socount result of 0, 1, or 2 each have deterministic meaning that's obvious by looking at the code.

What will happen if some tasks cancels itself? How would this interact with.stop()?

Do you mean the case where a child task callsstop() on its parent TaskGroup, or something else?

Cancellations (and thus taskgroup stops) happen when the nextawait … actually yields to the asyncio loop. Who the caller of the cancel or stop operation is doesn't matter.

Probably you want code examples for all of these?

what do you think about supporting cancel messages here?

I asked on Gitter, but I'm still unclear about how such a message would be accessed and surfaced.

It could be logged by the task that gets cancelled, or useful in debugging

I would keep it as-is and maybe add a message in the follow-up PR; this PR is big enough for the review.

I asked on Gitter, but I'm still unclear about how such a message would be accessed and surfaced.

My $0.02:

1. Assuming that message gets passed into each task, indeed, those tasks can do something with it (like identifying who cancelled it -- this is a private protocol within an app or library).
2. If we end up raising CancelledError out of theasync with block, the same is true for whoever catchesthat CancelledError.

can you add a test that a race function works, eg there's only one winner

asyncdeftest_race_one_winner():asyncdefrace(*fns):outcome=Noneasyncdefrun(fn):nonlocaloutcomeoutcome=awaitfn()tg.stop()asyncwithasyncio.TaskGroup()astg:forfninfns:tg.create_task(run(fn))event=asyncio.Event()record= []asyncdeffn_1():record.append("1 started")awaitevent.wait()record.append("1 finished")return1asyncdeffn_2():record.append("2 started")awaitevent.wait()record.append("2 finished")return2asyncdeftrigger_event():record.append("3 started")event.set()awaitasyncio.sleep(10)record.append("3 finished")outcome=awaitrace(fn_1,fn_2,trigger_event)self.assertEquals(outcome,1)self.assertListEquals(record, ["1 started","2 started","3 started","1 finished"])

I'm not sure we should expect only one winner, and vaguely recall Trio guidance against such expectations. I'm not sure such a guarantee is useful in practice, because a task wouldn't cancel a task group until its real work was completed, and there is no way to prevent multiple tasks finishing their work on the same scheduler pass (short of employing locks within the tasks).

Would you clarify your expectation? For example, "for any tasks transitively under a TaskGroup that may calltg.cancel(), only one such task is able to do so".

If they do finish on the same scheduler count only one will resume, so it can call .cancel() on sibling tasks to prevent them finishing

This behaviour is already required by staggered_race, and we want to be able to use a TaskGroup in staggered_race

does this bugfix need backporting to 3.12?

Can you think of a case where this bug is visible to the user? If it's visible, yes I'd make a separate PR with corresponding test that can be backported.

What is the use-case for this code?
If the bug is present -- let's create a separate issue and make a fix with the backport.
Anyway, I don't see how is this change related to adding.cancel() method.

Anyway, I don't see how is this change related to adding .cancel() method.

Suppressing exceptions out of the context manager is certainly needed to implementTaskGroup.cancel(). Without it, the following basic test will fail:

asyncdeftest_taskgroup_cancel_body(self):count=0asyncwithasyncio.TaskGroup()astg:tg.cancel()count+=1awaitasyncio.sleep(0)# <-- CancelledError will leak out of context managercount+=1self.assertEqual(count,1)

Note that the change isn't a blanket suppression. Code prior to thisreturn True explicitly raises any exception it wants propagated out of the context manager.

Ah it's visible in the Traceback returned for external or "native" cancellation. Ie a cancellation that propagates out of asyncio.run, because someone is using 3.10 semantics or waited on a executor future on a pool that was shutdown

Can you think of a case where this bug is visible to the user? If it's visible, yes I'd make a separate PR with corresponding test that can be backported.

I asked on Gitter, but I'm still unclear about how such a message would be accessed and surfaced.

I'm not sure we should expect only one winner, and vaguely recall Trio guidance against such expectations. I'm not sure such a guarantee is useful in practice, because a task wouldn't cancel a task group until its real work was completed, and there is no way to prevent multiple tasks finishing their work on the same scheduler pass (short of employing locks within the tasks).

Would you clarify your expectation? For example, "for any tasks transitively under a TaskGroup that may calltg.cancel(), only one such task is able to do so".

copying comment from@graingert

(please make all comments on the code so that there can be a thread and Resolve button)

can you test with eager tasks as well as regular tasks?

I think something like this:

classTestTaskGroupLazy(IsolatedAsyncioTestCase):loop_factory=asyncio.EventLoopclassTestTaskGroupEager(TestTaskGroupLazy):@staticmethoddefloop_factory():loop=asyncio.EventLoop()loop.set_task_factory(asyncio.eager_task_factory)returnloop

if you find the existing tests fail in eager tasks then probably just add the eager tests for your newly added tests.