On Sun, 28 Mar 2021, 12:34 am Irit Katriel via Python-Dev, < python-dev@python.org> wrote:
Hi Paul,
IIUC, you are saying that exception group should not be a builtin type because it is (1) complex (2) special-purposed. Instead, you propose that we make exception handling pluggable.
Note that (2) would be the *exact opposite* of the direction that we have taken exception handling in general: it used to be far more permissive than it is, and then got more restrictive over time to make structured exception handling more consistent. In particular, features like exception chaining and use case independent trace back printing only work because exception consumers can rely on all exceptions being instances of BaseException and having particular double-underscore attributes like "cause", "context", and "traceback" The lesson we've learned from Trio's experience is: * regular exceptions are still fine for most purposes * when they're not fine, they're not fine in a consistent way across a variety of use cases where the existing exception machinery currently loses or hides information, the problem isn't specific to Trio's nursery API I understand the temptation to generalise, but a general proposal would fail for the same reason the "user defined infix operators" PEPs failed: despite decades of experience, there just weren't compelling use cases for a general purpose feature. Instead, the proposal that succeeded was narrow: it targeted the feature that people actually wanted (an infix operator for matrix multiplication), rather than proposing more general machinery that could be used to build that feature. Cheers, Nick.