[Python-Dev] Proposal: make float.__str__ identical to float__repr__ in Python 3.2

[Mark Dickinson]

On Thu, Jul 29, 2010 at 8:16 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
> On Jul 29, 2010, at 11:47 AM, Mark Dickinson wrote:
>
>> Now that we've got the short float repr in Python, there's less value
>> in having float.__str__ truncate to 12 significant digits (as it
>> currently does).  For Python 3.2, I propose making float.__str__ use
>> the same algorithm as float.__repr__ for its output (and similarly for
>> complex).
>
> 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.  And those users it does have at the moment are the early
adopters, who with any luck may be more tolerant of this level of
breakage.  (By the time we get to 3.2 -> 3.3 that's probably not going
to be true any more.)  Really, this change should have gone into 3.1.

FWIW, the change broke very few of the standard library tests (as Eric
Smith verified):  there was a (somewhat buggy) doctest in
test_tokenize that needed fixing, and test_unicodedata computes a
checksum that depends on the str() of various numeric values.  Apart
from those, only test_float and test_complex needed fixing to reflect
the __str__ method changes.

> 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.

Mark