Remove MultiError and set strict_exception_groups=True by default

[Zac-HD]

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

[jakkdl]

In #2301 you previously said

I don't think we need a deprecation message; just a two-step approach of first changing the default to strict_exception_groups=True and later removing the option. A logical time for the latter would be shortly after 3.10 goes end-of-life and except* can therefore be assumed, which suggests that the midpoint (late 2024) as a reasonable time to change the default. The docs suggest that it'll change "once Python 3.11 and later versions are in wide use" so we can be a bit flexible.

Unless this issue is just to prep for a release in a year, this seems like moving up the date of the transition quite a bit.

[Zac-HD]

Yep, I now think we should change the default substantially sooner than I proposed last year. What changed?

• asyncio.TaskGroup has the always-raise-a-group "strict" semantics
• anyio matches that, and is becoming the normal way to write generally-compatible async libraries
  • this means that strict-by-default is (IMO) the better option for learners and new users, earlier than I expected
  • ⭐ libraries are almost always buggy when strict and non-strict semantics are mixed.
    Based on my experience over the last 18 months or so, I think it's pretty important for ecosystem correctness that we transition to the future default ASAP. I think it's the default that matters here though, so we can still allow legacy code to set strict=False.

If we wait another year, I'm concerned that we'll 'miss the wave'; if we catch it then I think support for Trio could end up standard in most async libraries. I've spoken to many maintainers who are interested in moving from asyncio to anyio, to support some mix of Trio users and TaskGroup-on-older-Pythons. IMO we need to be ready in time for mass adoption of Python 3.11, and that means starting ASAP.

[jakkdl]

All the major tasks are now resolved, only waiting on 0.23 to be released before going ahead with a PR for this. If anybody wants to consider the subtasks of looking for or documenting design patterns regarding inner nurseries it'd be lovely.

[jakkdl]

check for other places where Trio itself might raise groups when a single exception is intended

scanned for calls to open_nursery or MultiError:

1. DTLSEndpoint.serve explicitly mentions having an inner nursery so seems fine to raise ExceptionGroups
2. open_tcp_stream has special logic for turning the ExceptionGroup errors to an OSError
3. serve_listeners seems expected it might raise groups.
   • called by serve_tcp and serve_ssl_over_tcp, who both seem fine to rause groups
4. run_process looks like this will catch errors so they shouldn't get collected into a group.

I'm far from an expert on parsing concurrency code though, so if any of the above sounds strange please double-check it.

[Zac-HD]

Closing this issue, see #2929 for the remaining docs tasks.

And my sincere thanks again to everyone who contributed!