'%.1f' % 0.25          yields the string '0.2'

'%.1f' % 0.75          yields the string '0.8'

This is wrong.

You don't say why you think this behaviour is wrong, or what you'd expect to see instead.

Nevertheless, this behaviour is by design: the code `'%.1f' % x` rounds `x` to the nearest one-digit-after-the-point decimal number, and returns a string representation of that number. In the case `x=0.25`, there is no single nearest number: `0.2` and `0.3` are equally close to `0.25`, so a choice between the two has to be made. In keeping with many other languages, Python chooses the value with even last digit. (The original behaviour is inherited from the typical behaviour of the standard library strtod or dtoa functions in C.)

OK, not wrong, just unexpected.

Is this behaviour documented? Or are you just expected to know what C does?

On 16 November 2016 at 21:37, Mark Dickinson <report@bugs.python.org> wrote:

>
> Mark Dickinson added the comment:
>
> You don't say why you think this behaviour is wrong, or what you'd expect
> to see instead.
>
> Nevertheless, this behaviour is by design: the code `'%.1f' % x` rounds
> `x` to the nearest one-digit-after-the-point decimal number, and returns a
> string representation of that number. In the case `x=0.25`, there is no
> single nearest number: `0.2` and `0.3` are equally close to `0.25`, so a
> choice between the two has to be made. In keeping with many other
> languages, Python chooses the value with even last digit. (The original
> behaviour is inherited from the typical behaviour of the standard library
> strtod or dtoa functions in C.)
>
> ----------
> nosy: +mark.dickinson
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue28717>
> _______________________________________
>

-- 
Dr. William McIlhagga
Bradford School of Optometry & Vision Science,
Bradford University
Great Horton Road
Bradford BD7 1DP
UK

Room G23, Richmond tel. (44) (1274) 235957

> Is this behaviour documented? Or are you just expected to know what C does?

Indeed, it's not as well documented as it should be. I think that's partly for historical reasons: before Python 2.7, Python's % formatting more-or-less delegated directly to the underlying C sprintf library function, and so just inherited whatever the behaviour of that function happened to be on the target operating system. Because the C standard doesn't make guarantees about the behaviour of %f for ties, Python wasn't in a position to do so either.

But that excuse doesn't work any more with Python 2.7 and Python 3.x, where on most (but still not all) platforms, we're consistently rounding results using the usual round-ties-to-even rounding mode.

There's a currently open issue (#17259) to improve the documentation here.

Thanks, maybe I should get off my ass and contribute to the documentation
then ...

On 16 November 2016 at 22:30, Mark Dickinson <report@bugs.python.org> wrote:

>
> Mark Dickinson added the comment:
>
> > Is this behaviour documented? Or are you just expected to know what C
> does?
>
> Indeed, it's not as well documented as it should be. I think that's partly
> for historical reasons: before Python 2.7, Python's % formatting
> more-or-less delegated directly to the underlying C sprintf library
> function, and so just inherited whatever the behaviour of that function
> happened to be on the target operating system. Because the C standard
> doesn't make guarantees about the behaviour of %f for ties, Python wasn't
> in a position to do so either.
>
> But that excuse doesn't work any more with Python 2.7 and Python 3.x,
> where on most (but still not all) platforms, we're consistently rounding
> results using the usual round-ties-to-even rounding mode.
>
> There's a currently open issue (#17259) to improve the documentation here.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue28717>
> _______________________________________
>

-- 
Dr. William McIlhagga
Bradford School of Optometry & Vision Science,
Bradford University
Great Horton Road
Bradford BD7 1DP
UK

Room G23, Richmond tel. (44) (1274) 235957