[Python-Dev] Proposal: make float.str identical to float__repr__ in Python 3.2 (original) (raw)

Raymond Hettinger raymond.hettinger at gmail.com
Fri Jul 30 00:30:45 CEST 2010

When you proposed the idea at EuroPython, it seemed reasonable but we didn't go into the pros and cons. The downsides include breaking tests, changing the output of report generating scripts that aren't using string formatting, and it introduces another inter-version incompatibility. Yes, I agree that the change has potential for breakage; it's a change that probably would have been unacceptable for Python 2.7; for Python 3.2 I think there's a little more scope, since 3.x has fewer users.

+1 for making the change to 3.2 +0 for 2.7

The only obvious advantage is that it makes float.repr and float.str the same, making one less thing to explain. Can you elaborate on other advantages? Is there something wrong with the current way? That's one advantage; as mentioned earlier the difference between str and repr causes confusion for floats in containers, where users don't realize that two different operations are being used. This is a genuine problem: I've answered questions about this a couple of times on the #python IRC channel. Another advantage is that is makes 'str' faithful: that is, if x and y are distinct floats then str(x) and str(y) are guaranteed distinct. I know I should know better, but I've been bitten by the lack of faithfulness a couple of times when debugging floating-point problems: I insert a "print(x, y)" line into the code for debugging purposes and still wonder why my 'assertEqual(x, y)' test is failing even though x and y look the same; only then do I remember that I need to use repr instead. As you say, it's just one less surprise, and one less thing to explain: a small shrinkage of the mental footprint of the language.

Thanks for listing the advantages. Sounds like it is worth the cost.

It also really calls into question whether there are good reasons for other types to have a str that is different than their repr.

Raymond

More information about the Python-Dev mailing list