# Adding a GatheringTaskGroup

**URL:** <https://discuss.python.org/t/adding-a-gatheringtaskgroup/108194>\
**Category:** Ideas\
**Created:** [July 17, 2026, 10:21am UTC](https://discuss.python.org/t/adding-a-gatheringtaskgroup/108194 "2026-07-17T10:21:14Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![johng](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/johng/32/23313_2.png) [@johng](https://discuss.python.org/u/johng)\
**Post date:** [July 17, 2026, 10:21am UTC](https://discuss.python.org/t/adding-a-gatheringtaskgroup/108194/1 "2026-07-17T10:21:14Z")

</div>

Currently gathering results from a TaskGroup is quite involved, users must keep track of the submitted tasks and fetch .result() on each one.

```python
async with TaskGroup() as tg:
      r1 = tg.create_task(foo())
      r2 = tg.create_task(bar())
res = [r1.result(), r2.result()]

```

It would be nice for a new variant in the stdlib with this proposal to my origional question in stack overflow [https://stackoverflow.com/questions/75204560/consuming-taskgroup-response](https://stackoverflow.com/questions/75204560/consuming-taskgroup-response)

```python
async with GatheringTaskGroup() as tg:
    task1 = tg.create_task(foo())
    task2 = tg.create_task(bar())
print(tg.results())

```

---

<div class="post-metadata">

**Author:** ![jsbueno](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jsbueno/32/1210_2.png) [@jsbueno](https://discuss.python.org/u/jsbueno)\
**Post date:** [July 17, 2026, 5:21pm UTC](https://discuss.python.org/t/adding-a-gatheringtaskgroup/108194/2 "2026-07-17T17:21:12Z")

</div>

The main barrier I perceive here is that the “cheap happy path” for getting the results of several concurrent tasks is given by `asyncio.gather ` . Every project that will need to keep track of these tasks, act on failure, add more tasks as some are still being resolved, etc… has to come up with more complex patterns.

TaskGroups come with a subset of “tasks that must resolve together, all or nothing, and no one cares about their return value” - if you want anything different, taskgroup is not your “person”. You want the results: in a normal project, just write some logic around “asyncio.wait”.

At some point I did want a taskgroup that would not automatically cancel all sibling tasks on the first error inside one of the tasks - I had to mull out my own. (It is published in the `extraasync` package).

For as much as I like your idea here, I don’t see this kind of change coming to the stdlib. If you want to join in extraasync, drop me a line.

---

<div class="post-metadata">

**Author:** ![johng](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/johng/32/23313_2.png) [@johng](https://discuss.python.org/u/johng)\
**Post date:** [July 17, 2026, 6:33pm UTC](https://discuss.python.org/t/adding-a-gatheringtaskgroup/108194/3 "2026-07-17T18:33:16Z")

</div>

Thanks for you reply!

I thought though the decision to use .gather() and TaskGroups are driven by different considerations than the ease or expectation returning results? The docs also seem to suggest this the preferred model due to the additional guarantees.

No mention was made also that a TaskGroup is unsuited for returning results and .gather should be used instead.

> _TaskGroup_ provides stronger safety guarantees than _gather_ for scheduling a nesting of subtasks: if a task (or a subtask, a task scheduled by a task) raises an exception, _TaskGroup_ will, while _gather_ will not, cancel the remaining scheduled tasks.

> **[Coroutines and tasks](https://docs.python.org/3/library/asyncio-task.html#asyncio.TaskGroup)**
>
> Task groups combine a task creation API with a convenient and reliable way to wait for all tasks in the group to finish. | This section outlines high-level asyncio APIs to work with coroutines and Tasks. Coroutines, Awaitables, Creating tasks, Task...

---

<div class="post-metadata">

**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\
**Post date:** [July 17, 2026, 6:44pm UTC](https://discuss.python.org/t/adding-a-gatheringtaskgroup/108194/4 "2026-07-17T18:44:28Z")

</div>

The docs there probably shouldn’t call that a safety guarantee. It’s just a different behavioral choice, and people should pick the one most appropriate for their use case. There are plenty of good reasons not to cancel sibling tasks automatically.