On 3/4/2021 1:41 AM, Irit Katriel wrote:
On Thu, Mar 4, 2021 at 1:38 AM Glenn Linderman <v+pyt...@g.nevcal.com
<mailto:v%2bpyt...@g.nevcal.com>> wrote:
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.
I like explicit, and avoiding magic.
And this gives a compatibility story for outer loops that except:
Exception, and even for others cases that are not recoded for
ExceptionGroup handling.
And I guess what you are citing is a precedent from atexit, for raising
the last one.
And I guess in cases other than atexit, when raising an ExceptionGroup,
the coder of the new feature would still get more of a choice about
which Exception is more important, rather than the coder of the except
clauses. One could quibble that if ValueError and IndexError were both
part of the ExceptionGroup, that if the except clauses expected either
might happen, and listed them in ValueError and IndexError order, that
the intention might have been that ValueError was more interesting to
the except clause coder, whereas if the group is raised with the
IndexError as the singleton, that the group coder has the opposite
intention. I think it is more likely that the except clause coder simply
knew they were mutually exclusive and that the order of the clauses
didn't matter.
Thinking about the above a bit, the only existing except clause sequence
that would matter would be if both a base exception class and a derived
class were both listed in the except clauses. The derived exception
class should be listed before the base exception class or it wouldn't
get processed. So it is not clear that the order of the except clauses
really indicates any priority of interest on the part of the except
clause coder?
_______________________________________________
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/UAHFZSVVHRABZ7UQLHVLSXS53YXRIFCC/
Code of Conduct: http://python.org/psf/codeofconduct/
