* Demian Brecht <demianbrecht@gmail.com> [2015-02-20 10:24:53 -0800]:
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', '')) '<ProtocolError for url: 42 msg>’ str(URLError('reason')) '<urlopen error reason>’ str(Cookie(0, '', '', '4', '', '', '', '', '', '', '', 0, '', '', '', '')) '<Cookie = for :4>'
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) '<object object at 0x7f799a8a9070>' >>> repr(foo) '<object object at 0x7f799a8a9070>' This is exactly what you see above. ;) Florian -- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/