Mark Dickinson wrote:
> Out of interest, what does '%#.0f' % 1.5 produce on
> Python 2.7/Windows?  I'd expect to get '2.' both for
> round-half-to-even and round-half-away-from-zero.
> Does Windows round this down to '1.' instead?

Windows in trunk gives '2.'.

> I'm surprised by the %#.ng results for 0;  this looks
> like questionable behaviour (producing n+1 digits when
> only n significant digits were requested).  Is the MS
> implementation of printf directly responsible for this,
> or is the CPython code somehow adding the extra 0?
> If this is just the way that Windows behaves for formatting
> of zeros, then I suppose we could add code to work around
> this, but it's not clear that it's really worth it.

This is from a C program on Windows, using printf:
%#.0g: 0.0
%#.1g: 0.0
%#.2g: 0.00
%#.3g: 0.000

Same program on Linux:
%#.0g: 0.
%#.1g: 0.
%#.2g: 0.0
%#.3g: 0.00

In 2.6 on Windows:
 >>> '%#.1g' % 0.0
'0.0'
 >>> '%#.2g' % 0.0
'0.00'

In 2.6 on Linux:
 >>> '%#.1g' % 0.0
'0.'
 >>> '%#.2g' % 0.0
'0.0'

So this isn't a problem we caused with the short repr work, it's 
pre-existing. I don't think it's worth working around, but that's me. 
%-formatting should just die.

> I suspect that we're in for some complaints when
> Windows users discover that Python 3.1 string formatting
> does round-half-to-even rather than the round-half-up
> they're used to in Python 2.x.

But at least in 3.1 it will now be consistent cross-platform. Can't have 
it both ways!