Nick Coghlan added the comment:

While I agree it's reasonable to keep arbitrary value repr's out of these 
messages by default, I do think it would be desirable for someone sufficiently 
motivated to file a separate RFE about adding the value as a structured 
exception attribute so that custom sys.excepthook implementations and other 
"unhandled runtime exception" loggers may choose to handle the situation 

This wouldn't be about the cases where code is handling the remove() or index() 
call directly, but rather about those where third party library code isn't 
handling missing values correctly, so the debugging scenario a developer is 
faced with looks more like this than it does the examples in the OP here:

>>> some_library_function()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in some_library_function
  File "<stdin>", line 2, in some_other_library_function
ValueError: list.remove(x): x not in list

Getting that kind of traceback in the logs for a production failure in a 
distributed system is all kinds of frustrating since you *know* the interpreter 
knew what "x" was when the error happened, it just isn't passing that 
information along to the developer that's trying to figure out how and why it 


Python tracker <>
Python-bugs-list mailing list

Reply via email to