After some conversations with Yury, and encouraged by the SC's approval of PEP-654, I am proposing to add a new class, asyncio.TaskGroup, which introduces structured concurrency similar to nurseries in Trio.

I started with EdgeDb's TaskGroup implementation (https://github.com/edgedb/edgedb/blob/master/edb/common/taskgroup.py) and tweaked it only slightly. I also changed a few things in asyncio.Task (see below).

The key change I made to EdgeDb's TaskGroup is that subtasks can keep spawning more subtasks while __aexit__ is running; __aexit__ exits once the last subtask is done. I made this change after consulting some Trio folks, who knew of real-world use cases for this behavior, and did not know of real-world code in need of prohibiting task creation as soon as __aexit__ starts running. I added some tests for the new behavior; none of the existing tests needed to be adjusted to accommodate this change.

(For other changes relative to the EdgeDb's TaskGroup, see #75453.)

In order to avoid the need to monkey-patch the parent task, I added two new methods to asyncio.Task, .cancelled() and .uncancel(), that manage a flag corresponding to __cancel_requested__ in EdgeDb's TaskGroup.

**This introduces a change in behavior around task cancellation:**

• A task that catches CancelledError is allowed to run undisturbed (ignoring further .cancel() calls and allowing any number of await calls!) until it either exits or calls .uncancel().

This change in semantics did not cause any asyncio unittests to fail. However, it may be surprising (especially to Trio folks, where the semantics are pretty much the opposite, once a Trio task is cancelled all further await calls in that task fail unless explicitly shielded).

For the TaskGroup tests to pass, we require a flag that is not cleared. However, it is probably not really required to ignore subsequent .cancel() calls until .uncancel() is called. This just seemed more consistent, and it is what @asvetlov proposed above and implemented in #75494 (using a property .__cancel_requested__ as the API).

New changeset 602630a by Guido van Rossum in branch 'main':
bpo-46752: Add TaskGroup; add Task..cancelled(),.uncancel() (GH-31270)
602630a

Remaining TODO list:

• Add a test showing the need for the .uncancel() call in __aexit__()
  (currently on line 97). Dropping that line does not cause any tests
  to fail.
• Ensure the taskgroup tests are run with the C and Python Task
  implementations.
• Rename tests to have meaningful names.
• I have a few ideas for minor cleanups that I will do later.
• Documentation and What's New entry (in a separate PR, probably).
• Update the docs in a few places to de-prioritize asyncio.gather()
  and steer people towards TaskGroups.

(We could also add something like Trio's cancel scopes, e.g. based on
Andrew Svetlov's async-timeout, which has a mature API.
But that should be a separate bpo issue.)

For your TODO list (not sure how else to communicate this):

I agree with the de-emphasis of gather(). I think adding another version of gather() that cancels all the remaining tasks if one fails would also be good, unless you think it is completely redundant due to TaskGroups. This idea was originally mentioned in https://bugs.python.org/issue31452 as a bug, and determined to be "works as designed". So now making an all-cancel() version of gather() is an idiom that people keep recoding, e.g. https://stackoverflow.com/questions/59073556/how-to-cancel-all-remaining-tasks-in-gather-if-one-fails.

@dhalbert, it's probably better to file a new issue if you want changes to gather(). Although I suppose that if we want to deemphasize it, we shouldn't be adding new features to it. My own new feature idea would be to have it wait for all tasks and then if there are any exceptions, raise an ExceptionGroup. That (like any new gather() behaviors) would require a new keyword-only flag to gather(). If we're going to deemphasize it I might not bother though.

There's one thing that gather() does that TaskGroup doesn't: it gives us the return values from the tasks. The question is whether that's useful. If it is maybe we should *not* deepmhasize gather() quite as much and then adding new features would be okay.

I've created a separate issue for cancel scopes: bpo-46771.

There's one thing that gather() does that TaskGroup doesn't: it gives us the return values from the tasks.

That's easy to do with task groups too:

  async with TaskGroup() as g:
      r1 = g.create_task(coro1())
      r2 = g.create_task(coro2())

  print(r1.result())

  # or
  print(await r2)  # I *think* this should work

I have a PR up to typeshed to add the new Task methods and a new stub file taskgroups.pyi: python/typeshed#7240

New changeset d851216 by Guido van Rossum in branch 'main':
bpo-46752: Slight improvements to TaskGroup API (GH-31398)
d851216

New changeset e7130c2 by Andrew Svetlov in branch 'main':
bpo-46752: Uniform TaskGroup.__repr__ (GH-31409)
e7130c2

Documentation and What's New entry (in a separate PR, probably).

Is there a plan or PR yet for documenting TaskGroup before 3.11b1? I can find it and there is no documentation in main AFAICT.

No, that’s why this issue is still open.

Adding deferred blocker as it would be nice to have docs before the rc.

I'll try to write docs for taskgroups.

We should also document the new Task.uncancel() method, and the subtly new cancellation semantics in general. I'd like to do that in a separate PR: unlike TaskGroup, few people will care, and those that do can read the code for now.

Now the docs are up we can close this.