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

[Guido van Rossum]

On Thu, Jul 29, 2010 at 1:30 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
> 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.

+1 from me for all the reasons Mark mentioned.

-- 
--Guido van Rossum (python.org/~guido)