On Sun, Feb 28, 2021 at 2:40 AM Irit Katriel <iritkatriel@googlemail.com> wrote:

In earlier versions of the PEP ExceptionGroup was not immutable and split actually removed matching exceptions from it. 
It was also iterable so you could get a flat list of all the contained leaf exceptions. Then we changed it.

ExceptionGroup is a tree of exceptions, and the internal nodes of the tree (which are ExceptionGroups) have metadata on them -  context, cause, traceback.
If you want the full traceback of a leaf exception you need to concatenate the tracebacks of all the exceptions on the path from the root to the leaf.
If you flatten an ExceptionGroup and create a new list ExceptionGroup(list(eg)) you don't lose metadata (unless eg's tree has depth 1).

Is this a typo? Did you mean "If you flatten [it] and create a new list... you *do* lose metadata (unless ... depth 1)"?
 
Similarly, if you add an exception it needs to have matching metadata to the ExceptionGroup you are adding it to. It's too easy to get that wrong.

split() and subgroup() take care to preserve the correct metadata on all the internal nodes, and if you just use them you only make safe operations.
This is why I am hesitating to add iteration utilities to the API. Like we did, people will naturally try that first, and it's not the safest API.

We actually have the  OSErrors example in the PEP, just above https://www.python.org/dev/peps/pep-0654/#caught-exception-objects:

try:
    low_level_os_operation()
except *OSerror as errors:
    raise errors.subgroup(lambda e: e.errno != errno.EPIPE) from None

--
--Guido van Rossum (python.org/~guido)