[Python-Dev] Backport new float repr to Python 2.7?

[Guido van Rossum]

On Sun, Oct 11, 2009 at 12:44 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Mark Dickinson]
>>
>> - string to float *and* float to string conversions are both guaranteed
>>  correctly rounded in 3.x: David Gay's code implements the conversion
>>  in both directions, and having correctly rounded string -> float
>>  conversions is essential to ensure that eval(repr(x)) recovers x exactly.
>
> IMO, that is so important that it should be considered a bug fix.

It looks like the majority of posters so far is +0 to +1 on this, and
I don't want my -0 to stand in the way of progress.

But make no mistake, it *is* a feature, not a bug fix. It took a
multidisciplinary team a year to implement it -- from existing
portable code in C! Mark wrote easily a page in favor of introducing
it. Those are signs of a Feature. The original behavior was no more a
bug than the distinction between int and long, or the existence of
classic and new classes, or the GIL. These were all deliberate design
decisions made as compromises between different requirements.

And make no mistake, I like this feature in 3.1. Just as I like the
new int type, the new str type, the new classes, the new rich
comparisons. The new f.p. repr() may look like a small feature -- but
it's a feature that few other languages have!

If I had a doctest that depended on the vagaries of f.p. repr(), I
would probably change the doctest to use simpler numbers; getting
1./3.+1./3. to be exactly 2./3. is hard enough, but I might rewrite my
test to use 1/2. + 1/2. = 1. instead. So the doctest argument isn't
all too strong.

Carrot-wise the feature is quite strong (see Mark's page of arguments
in favor) -- but that works also in favor of inclusion on 2.7.

In the end somebody needs to do the work. If it can reuse much of the
work done for 3.1, then hopefully it will be done in much less time
than the original was done. It looks like someone wants to do this
work. I wish them well.

But doing this work will mean not doing other work on 2.7 that may be
more productive.

PS. str(x) still seems to be using %.12g -- shouldn't it be made equal
to repr() in 3.1 or 3.2? *That* I would call a bug, an oversight.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)