Rejecting PEP 473: Adding structured data to built-in exceptions
![](https://secure.gravatar.com/avatar/e8600d16ba667cc8d7f00ddc9f254340.jpg?s=120&d=mm&r=g)
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). Thanks to Sebastian Kreft for taking the time to write the PEP in the first place.
![](https://secure.gravatar.com/avatar/4dc045274504f02e7a0b6264e96da643.jpg?s=120&d=mm&r=g)
Hi, While I would like to get such new attributes, I see drawbacks as blocker issues and so I am fine with this PEP rejection. Performance is too critical for most common exceptions. For me one blocker issue is the high risk of creating reference cycles. And the weak reference API isn't the most practical :-( Moreover I expect slowdown, whereas exceptions are already expensive :-( Recently, internal code to get an attribute has been reworked to avoid exception whenever possible, and it made the code faster. Victor Le vendredi 15 mars 2019, Brett Cannon <brett@python.org> a écrit :
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). Thanks to Sebastian Kreft for taking the time to write the PEP in the first place.
-- Night gathers, and now my watch begins. It shall not end until my death.
participants (2)
-
Brett Cannon
-
Victor Stinner