Description
Goal
Our long-term goal is for Trio and our users to use the builtin ExceptionGroup
type and except*
syntax, and to always raise ExceptionGroup
where we might ever do so. #2213 started moving us towards this goal, following discussion in #2211 (and #611), and this issue is about how and when we might finish it.
Proposal
Remove MultiError
, using the builtin (or backported) ExceptionGroup
type and catching logic instead. At the same time, change the default value of strict_exception_groups
to True
, to match the behavior of asyncio and anyio TaskGroup
.
Later, when strict_exception_groups=False
has become very rare or Python 3.10 reaches end of life, we'll remove the strict_exception_groups
argument entirely. That's a future issue!
Timing and todos
With the growing popularity of ExceptionGroup
in general and anyio
in particular, I'm keen to ship this in the next few months - making Trio as "normal" as possible makes it much easier for prospective users to adopt and learn. That said, I think there are a few things we should or could get done first:
- Wait for
anyio
4.0, which uses the standardExceptionGroup
type - IPython now handles
ExceptionGroup
so we can remove our workaround Remove special handling due to IPython lacking support for exception groups #2702 - Release Trio 0.23 and get our new-and-improved type annotations shaken out.
- Fix
strict_exception_groups=True
"leaks" the implementation-detail nursery innursery.start(fn)
#2611- check for other places where Trio itself might raise groups when a single exception is intended
- consider documenting any design patterns we like or dislike for interfaces with an "inner nursery", c.f. Hide MultiErrors trio-websocket#132
- Propose moving our
apport
monkeypatch to theexceptiongroup
backport, Add exceptiongroup support to third party projects agronholm/exceptiongroup#23 / monkeypatch apport excepthook agronholm/exceptiongroup#88