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 <c...@cskk.id.au> wrote: > On 26Feb2021 02:44, Irit Katriel <iritkatr...@googlemail.com> wrote: > >On Fri, Feb 26, 2021 at 2:00 AM Guido van Rossum <gu...@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 <c...@cskk.id.au> > -- --Guido (mobile)
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KLQTLTUCUGQ4ZKQA5NFW4SR7MIDPUME4/ Code of Conduct: http://python.org/psf/codeofconduct/
