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.