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 years.