Since tweaking the built-in exceptions is so far-reaching, probably at least discussing each proposed change (one at a time, not 5 at once) would be the minimum. Otherwise you could do a PEP, but once again you're looking at a PEP per exception. I think it's really going to come down to how big of an addition it is per exception, how easy it would be to have a memory leak, what the API to setting the attribute(s) would look like, etc.
On Sat, Mar 13, 2021 at 1:22 PM Victor Stinner <vstin...@python.org> wrote: > Context: PEP 473 "Adding structured data to built-in exceptions" > proposed in 2014. > https://www.python.org/dev/peps/pep-0473/ > > Abstract: "Exceptions like AttributeError, IndexError, KeyError, > LookupError, NameError, TypeError, and ValueError do not provide all > information required by programmers to debug and better understand > what caused them. Furthermore, in some cases the messages even have > slightly different formats, which makes it really difficult for tools > to automatically provide additional information to diagnose the > problem. To tackle the former and to lay ground for the latter, it is > proposed to expand these exceptions so to hold both the offending and > affected entities." > > For example the PEP proposes to add "target" and "attribute" > attributes to AttributeError. > > PS: Please give at least the PEP title for me when you mention a PEP > only by its number, I'm unable to remember what are the 500+ PEP :-( > > Victor > > On Sat, Mar 13, 2021 at 7:49 PM Sebastian Kreft <skr...@gmail.com> wrote: > > > > Hi dev-team, I'm reopening the discussion of PEP 473, which was closed > due to: > > > > The steering council felt the PEP was too broad and not focused enough. > Discussions about adding more attributes to built-in exceptions can > continue on the issue tracker on a per-exception basis (and obviously here > for any broader points, e.g. performance implications as I know that has > come up before when the idea of storing relevant objects on exceptions). > > > > Before the PEP was rejected by the SC, I had submitted > https://github.com/python/cpython/pull/6271 and the last response said: > > > > You may propose a newly revised PEP which overcomes the last SC feedback. > > But without the accepted PEP, this PR can not be merged. > > > > Please clarify how can I proceed with adding some of the specified > fields to the mentioned exceptions. Should I create a new PEP as suggested > in the PR or should we create individual BPO issues for each exception > modification. > > > > -- > > Sebastian Kreft > > _______________________________________________ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/4XVFFNBHXN5KBTHJGMX6ZTN6KOW4Z7UG/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/PLPUG6MFVHHHVONJK6ZHPORCQYJS5QTH/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/C7UZ7MH3TRT4M3NNYDEDNWX5WIXVOVBX/ Code of Conduct: http://python.org/psf/codeofconduct/
