Raymond Hettinger added the comment:

Thinking back over my 17 years of using Python, I really don't think this is 
needed at all.  I can't think of a single situation where it would have helped.

In some cases, the change would be detrimental to readability, introducing 
clutter into an otherwise clear error message.  The OP's example of 
"ValueError: 4 is not in list" is atypical. A more typical example would be 
"ValueError: <__main__.TensorElementPlaceholder object at 0x106489e48> is not 
in list".

As a Python instructor, I've become acutely aware that tracebacks already have 
usability issues due to visual clutter and an unpleasant overall appearance.  
IMO, this proposal would sometimes make it worse by adding more noise for the 
reader to filter out.

Brett's idea is an improvement to the original proposal. By attaching the 
object to the exception rather than squeezing its representation into the 
string, you avoid making the error message hard to read and avoid the 
speed/space costs from computing the __repr__ on arbitrary objects.  That said, 
I don't think there is any programmatic benefit to having the object in the 
exception.  When you call "a.remove(b)", you already have "b" and it would be 
pointless to re-extract it with "except ValueError as e:  b = e.args[-1]".

I'm also concerned that the proposed changes sweep across the core affecting 
code that has been deployed and stable for almost two decades.

Given the dubious benefits and potential detriments, I vote for declining this 
proposal and favoring the stable deployed code that has worked fine for many 


Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list

Reply via email to