On 3/3/2021 2:49 PM, Irit Katriel via
Python-Dev wrote:
That's an interesting idea.
Do you mean that one exception gets handled and the rest
of the group is reraised? Or discarded?
The value of sys.exc_info() (and the e in "except T as
e:") needs to be a single naked exception. So if there is
more than one match in the group we would need to pick one
(let's say the first in DFS order).
If we do this, then we have this situation. Before
ExceptionGroups, you got to choose which of the exceptions
you have is the most important, and you raised only that
one. Now you raise a bunch of them and the order of the
except clauses in caller's code determines which one of them
counts and which ones are discarded. What do you make of
that?
You _could_ implement it as you said, but remember, you that with
this idea, you are changing how except clauses work—so instead of
making the order of the except clauses determine which one counts
most, you could instead do something else.
One alternative idea would be to take the "first in DFS order" and
see if it matches any of the except clauses, and if so, process that
one. If not, then pick the next, and see if it matches, until one
is found that matches, and can be processed.
Or we could make it explicit:
add an optional arg to ExceptionGroup like
ExceptionGroup("eg", list_of_exceptions, singleton=None)
In the example of atexit, where currently it raises only the last exception from your callbacks, it will instead raise
ExceptionGroup("atexit errors", all_exceptions, singleton=last_exception)
Then except* works as before, ignoring the singleton. But except matches the singleton.
And there's no magic where you can be surprised about which exception except chose to look at.