Irit Katriel <iritkatr...@gmail.com> added the comment:
To summarise the discussion so far:
The arguments in favour of changing exception matching to match on virtual base
classes are:
1. It is confusing that it doesn't follow issubclass semantics.
2. Two use cases were presented as practical motivation.
- one in msg135521, which can be solved with the pattern in msg200418
- one in msg200829, which is typically done with
except:
if condition:
handle
raise
The arguments against the change are
1. safety - calling python code from the exception propagation code
2. possible performance impact
I am not too worried about the performance of exception handling. I am also not
impressed by the use cases.
For me it's mostly between the safety issue and the aesthetic language
consistency issue.
The code path from when a RAISE opcode executes and until control passes to an
except clause, is a very sensitive one and I have a lot of sympathy to the
position that we should just change the documentation to say that matching is
on non-virtual base classes. It is much easier to implement this feature than
to predict how it would behave in all cases.
If we do decide to implement this, then I don't think the patch is the way we
should do it. If the IsSubclass call fails, this should result in a "goto
error", like when the match type is invalid:
https://github.com/python/cpython/blob/7ba1cc8049fbcb94ac039ab02522f78177130588/Python/ceval.c#L3831
This means that the failure to determine whether the exception is a match is
the dominant error, rather than something we print to the ether via the
unraisablehook and interpret as non-match.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue12029>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
