PEP 830: Rework Motivation example to actually produce multiple errors

The original TaskGroup example only ever produced one sub-exception because
TaskGroup cancels siblings on first failure. Switch to a three-backend
asyncio.gather(..., return_exceptions=True) pattern that collects every
failure, and replace the illustrative output with real output captured from
the reference implementation. Update the sys.excepthook rejection to drop
the now-stale TaskGroup reference.

Author: gpshead

peps/pep-0830.rst

@@ -31,10 +31,10 @@ Currently there is no standard way to obtain this information.  Python authors
 must manually add timing to exception messages or rely on logging frameworks,
 which can be costly and is inconsistently done and error-prone.
 
-Consider an async service that fetches data from multiple backends concurrently
-using ``asyncio.TaskGroup``.  When several backends fail, the resulting
-``ExceptionGroup`` contains all the errors but no indication of their temporal
-ordering::
+Consider an async service that fetches data from multiple backends
+concurrently and reports every failure rather than failing fast.  The
+resulting ``ExceptionGroup`` contains all the errors in submission order,
+with no indication of when each one occurred::
 
     import asyncio
 
@@ -50,52 +50,53 @@ ordering::
         await asyncio.sleep(2.3)
         raise TimeoutError("Recommendation service timeout")
 
-    async def fetch_inventory(items):
-        await asyncio.sleep(0.8)
-        raise KeyError("Item 'widget-42' not found in inventory")
-
     async def get_dashboard(uid):
-        async with asyncio.TaskGroup() as tg:
-            tg.create_task(fetch_user(uid))
-            tg.create_task(fetch_orders(uid))
-            tg.create_task(fetch_recommendations(uid))
-            tg.create_task(fetch_inventory(['widget-42']))
+        results = await asyncio.gather(
+            fetch_user(uid),
+            fetch_orders(uid),
+            fetch_recommendations(uid),
+            return_exceptions=True,
+        )
+        errors = [r for r in results if isinstance(r, Exception)]
+        if errors:
+            raise ExceptionGroup("dashboard fetch failed", errors)
 
     asyncio.run(get_dashboard("usr_12@34"))
 
 With ``PYTHON_TRACEBACK_TIMESTAMPS=iso``, the output becomes:
 
 .. code-block:: text
 
-    Traceback (most recent call last):
-      ...
-    ExceptionGroup: unhandled errors in a TaskGroup (4 sub-exceptions)
+      + Exception Group Traceback (most recent call last):
+      |   File "service.py", line 26, in <module>
+      |     asyncio.run(get_dashboard("usr_12@34"))
+      |   ...
+      |   File "service.py", line 24, in get_dashboard
+      |     raise ExceptionGroup("dashboard fetch failed", errors)
+      | ExceptionGroup: dashboard fetch failed (3 sub-exceptions) <@2026-04-19T07:24:31.102431Z>
       +-+---------------- 1 ----------------
         | Traceback (most recent call last):
-        |   File "service.py", line 11, in fetch_orders
-        |     raise ValueError(f"Invalid user_id format: {uid}")
-        | ValueError: Invalid user_id format: usr_12@34 <@2025-03-15T10:23:41.142857Z>
+        |   File "service.py", line 5, in fetch_user
+        |     raise ConnectionError(f"User service timeout for {uid}")
+        | ConnectionError: User service timeout for usr_12@34 <@2026-04-19T07:24:29.300461Z>
         +---------------- 2 ----------------
         | Traceback (most recent call last):
-        |   File "service.py", line 7, in fetch_user
-        |     raise ConnectionError(f"User service timeout for {uid}")
-        | ConnectionError: User service timeout for usr_12@34 <@2025-03-15T10:23:41.542901Z>
+        |   File "service.py", line 9, in fetch_orders
+        |     raise ValueError(f"Invalid user_id format: {uid}")
+        | ValueError: Invalid user_id format: usr_12@34 <@2026-04-19T07:24:28.899918Z>
         +---------------- 3 ----------------
         | Traceback (most recent call last):
-        |   File "service.py", line 19, in fetch_inventory
-        |     raise KeyError("Item 'widget-42' not found in inventory")
-        | KeyError: "Item 'widget-42' not found in inventory" <@2025-03-15T10:23:41.842856Z>
-        +---------------- 4 ----------------
-        | Traceback (most recent call last):
-        |   File "service.py", line 15, in fetch_recommendations
+        |   File "service.py", line 13, in fetch_recommendations
         |     raise TimeoutError("Recommendation service timeout")
-        | TimeoutError: Recommendation service timeout <@2025-03-15T10:23:43.342912Z>
+        | TimeoutError: Recommendation service timeout <@2026-04-19T07:24:31.102394Z>
+        +------------------------------------
 
-The timestamps immediately reveal that the order validation failed first
-(at .142s), while the recommendation service was the slowest at 2.3 seconds.
-That could also be correlated with metrics dashboards, load balancer logs, or
-traces from other services or even logs from the program itself to build a
-complete picture.
+The sub-exceptions are listed in submission order, but the timestamps reveal
+that the order validation actually failed first (at 28.899s), the user
+service half a second later, and the recommendation service last after 2.3
+seconds.  These can also be correlated with metrics dashboards, load
+balancer logs, traces from other services, or the program's own logs to
+build a complete picture.
 
 
 Specification
@@ -401,7 +402,7 @@ Using ``sys.excepthook``
 
 ``sys.excepthook`` runs only when an uncaught exception reaches the top
 level, at display time rather than when the exception was created.  For the
-motivating ``TaskGroup`` example, the hook would fire once for the resulting
+motivating example above, the hook would fire once for the resulting
 ``ExceptionGroup`` after all tasks have completed, so every sub-exception
 would receive the same timestamp.  Exceptions that are caught and logged
 never reach the hook at all.
@@ -622,7 +623,7 @@ Change History
     coarse-resolution clock; reworded the Runtime API rejection.
   - Added an Open Issues section covering display location, benchmarking the
     ``sys.monitoring`` alternative, and recording time of first raise.
-  - Made the Motivation example self-contained.
+  - Reworked the Motivation example to be self-contained.
 
 
 Copyright