[Python-ideas] Arguments to exceptions

[Nick Coghlan]

On 7 July 2017 at 10:26, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Paul Moore wrote:
>>
>> But no-one manually raises NameError, so Ken's example wouldn't work
>> with "real" NameErrors.
>
> Part of his suggestion was that core and stdlib code would
> move towards using attributes. The NameError example makes
> sense in that context.

I haven't been following the thread, so making sure this is stated
explicitly: as a matter of general policy, we're OK with enhancing
builtin exception types to store additional state for programmatic
introspection (when we aren't, it's usually because the exception is
often raised and then handled in contexts where it never actually gets
instantiated, and you can't use that trick anymore if you add
meaningful state to the exception instance).

Actually doing that isn't especially hard conceptually, it's just
tedious in practice, since somebody has to do the work to:

1. Decide what field they want to add
2. Figure out how to support that in the C API without breaking
backwards compatibility
3. Go through the code base to actually set the new field in the
relevant locations

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.

Cheers,
Nick.

P.S. It isn't a coincidence that the import system's exceptions
started to become significantly more informative *after* Brett rewrote
most of it in Python :)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia