On 7 July 2017 at 10:26, Greg Ewing <greg.ew...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
