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 standard ExceptionGroup 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 typing error on master in _core/_multierror since exceptiongroup==1.1.3 #2783
• Fix strict_exception_groups=True "leaks" the implementation-detail nursery in nursery.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 the exceptiongroup backport, Add exceptiongroup support to third party projects agronholm/exceptiongroup#23 / monkeypatch apport excepthook agronholm/exceptiongroup#88