We really don’t want users pushing non-exceptions into the list, nor do we want e.g. KeyboardInterrupt to be added to a (non-Base-) ExceptionGroup.

There’s a pattern for what you propose using the split() method and a lambda, or you can keep the exceptions in a list and re-wrap them at the end.

On Sat, Feb 27, 2021 at 20:41 Cameron Simpson <cs@cskk.id.au> wrote:
On 26Feb2021 02:44, Irit Katriel <iritkatriel@googlemail.com> wrote:
>On Fri, Feb 26, 2021 at 2:00 AM Guido van Rossum <guido@python.org> wrote:
>> OT: Is ExceptionGroup *really* immutable in the current
>> implementation? As
>> long as the 'errors' field is a list, I think one could mutate the list
>> directly.
>
>It's not, but we were going to make it an immutable tuple.

Could you say why? Other than wanting to discourage mutation happy code
getting out there?

The reason I ask is that the scenario which comes to my mind is
something like:

    except *OSError as e:

AIUI "e" is an ExceptionGroup containing only OSErrors. So, one common
thing in my own code is this:

    try:
        do something with a file
    except OSError as e:
        if e.errno == ENOENT:
            # file is missing, but that is ok
            # because we treat it like an empty file
        elif ... some other ok situation ...
        else:
            raise

My natural inclination with an ExceptionGroup would be to winnow the
OSErrors I'm handed, and push the _unhandled_ errors back into the
original ExceptionGroup. That way, after the various except* clauses, a
nonempty ExceptionGroup would remain with the unhandled errors, and it
might perhaps be reraised then.

Cheers,
Cameron Simpson <cs@cskk.id.au>
--
--Guido (mobile)