* Demian Brecht
These and other implementations return a string representation of the instance’s value, not a string representation of the object itself. Whereas elsewhere in the standard library:
str(ProtocolError('url', 42, 'msg', '')) '
’ str(URLError('reason')) '<urlopen error reason>’ str(Cookie(0, '', '', '4', '', '', '', '', '', '', '', 0, '', '', '', '')) ' ' The specific problem that I encountered was when swapping an IntEnum implementation for ints in http.client, which caused a change in logging output (from int.__str__ to Enum.__str__), which was a bit of a surprise, especially given the value is a builtin type.
I think that a decent rule around the usage of __str__ is that it should be a string representation of the value, not of the object. Failing the ability to logically coerce the value to a string, it should simply fall back to repr(obj).
Of course, I realize that the chances of this change being made to such a fundamental (and largely inconsequential) feature are likely nil, but I thought I’d share my thoughts anyways.
>>> foo = object() >>> str(foo) '