On 7 July 2017 at 12:18, Nick Coghlan <ncoghlan@gmail.com> wrote:
By contrast, we're incredibly wary of trying to enhance exception behaviour by way of `BaseException` changes due to our past negative experiences with that during the original implementation of PEP 352: https://www.python.org/dev/peps/pep-0352/#retracted-ideas
In principle, such approaches sound great. In practice, they tend to fall apart once they try to cope with the way CPython's internals (as opposed to user level Python code) creates and manipulates exceptions.
To elaborate on the potential problem with the specific proposal in this thread: adding arbitrary kwargs support to BaseException would be straightforward. Adding arbitrary kwargs support to the dozens of exceptions defined as builtins and in the standard library would *not* necessarily be straightforward, *and* would potentially get in the way of adding more clearly defined attributes to particular subclasses in the future. It would also create potential inconsistencies with third party exceptions which may or may not start accepting arbitrary keywords depending on how they're defined. As a result, our advice is to *avoid* trying to come up with systemic fixes for structured exception handling, and instead focus on specific use cases of "I want *this* exception type to have *that* attribute for *these* reasons". Those kinds of proposals usually don't even rise to the level of needing a PEP - they're just normal RFEs on the issue tracker. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia