Tim Peters wrote:
> This has nothing to do with what will or won't satisfy me, either.  I'm
> happy with what Python currently does, which is to rely on #3 above. 
> That's explainable (what's hard about understanding "%.17g"?), and
> relies only on what the 754 standard requires.
> 
> There is no easy way around this, period.  If you're willing to give up
> on float(repr(x)) == x cross-754-platform in some cases (and are willing
> to be unable to spell out /which/ cases), then many easy alternates exist.
> 
> Maybe this is a missing fact:  I don't care whether float(repr(x)) == x.
>  It would, for example, be fine by me if Python used a plain %.8g format
> for str and repr.  But I'm not indulging wishful thinking about the
> difficulties in ensuring float(repr(x)) == x either ;-)

Time is right.

The only way to ensure that it works on all platforms is a full and
mathematical correct proof of the algorithm and all functions used by
the algorithms. In the mean time *we* are going to release Python 40k
while *you* are still working on the proof. *scnr* :)

I like to propose a compromise. The patch is about making the
representation of a float nicer when users - newbies and ordinary people
w/o mathematical background - work on a shell or do some simple stuff.
They want a pretty and short representation of

2.2
>>> "My value is %s" % (11./5.)
'My value is 2.2'

The latter already prints 2.2 without the patch but the former prints
2.2000000000000002 on my machine. Now here comes the interesting part.
In 2.6 the shell uses PyObject_Print and the tp_print slot to print a
float. We can overwrite the str() and tp_print slot to use the new
algorithm while keeping the old algorithm for repr().

Unfortunately the tp_print slot is no longer used in Python 3.0. It
could be resurrected for this purpose (object.c:internal_print()).

str(1.) -> new code
repr(1.) -> old and good representation
>>> 1. -> new code

Christian