On 10/28/2011 1:51 PM, Guido van Rossum wrote:
In my view, str() and repr() are both for human consumption (though in somewhat different contexts). If tweaking them helps humans understand the output better then let's tweak them.
With that explanation, I am fine with whatever you decide. Without expensive study, 'human friendliness' is ultimately a judgment call.
If you as a developer feel particularly anal about how you want your object printed, you should avoid repr() or str() and write your own formatting function.
The only guarantee in the str doc is that str(astring) is astring. (The repr doc says much more, but you are not currently proposing to change that.) With that guarantee, users have complete control of output. When comparing actual to expected strings, I should and will continue using .__name__ and .format().
If as a programmer you feel the urge to go parse the output of repr() or str(), you should always *know* that a future version of Python can break your code,
doctest is known to be fragile and has gimmicks already to avoid breakage. That tail should not wag the dog.
and you should file a feature request to have an API added to the class so you won't have to parse the repr() or str().
I agree that classes should make all vital info available as Python objects that one can compute with. A similar issue came on the tracker with the suggestion that the dis module should gain a computation friendly interface to return the objects that currently get formatted into each line.