homepage

10e667.__format__('+') returns '+1.0#INF'
vs:
10e667.__format__('') which returns 'inf'
The docs say 'inf' is right.

Here's a patch to add tests for this and a few other problems with
formatting inf/-inf/nan, as well as a patch that fixes the problems.

This is a duplicate of 4799, which I've closed.
I've resisted fixing this because differences in various platform
sprintf's have made it difficult. Now that Mark Dickinson and I are
close to removing the use of sprintf for float formatting, I'll have the
tools to deal with this better.
Not sure what this means for 2.7, yet. We're not planning on backporting
the new float formatting to 2.7.

Actually this isn't quite a duplicate of 4799, but it's close. Any fix
to this issue will also address 4799's original report:
> On windows, with python 2.6, s = '%s' % float('inf') is 'inf',
> but s ='%f' % float('inf') is equal to '1.#INF'.

The patch I submitted adds a special-case for inf/-inf/NaN so that
sprintf is avoided for those values. Should work on any platform, I
believe.
I'm not sure how it interacts with your 3.x plans. Seems like it would
be a good patch for 2.7 at least, though.
(and the patch that adds tests should go into both 2.7 and 3.x)

Agreed. That might be the strategy for 2.7.
But it depends on how much of the other float and int formatting code I
can re-use from 3.1. If I can hide the 2.7/3.1 differences in
PyOS_double_to_string, then the 2.7 and 3.1 code should be identical,
and the fix will be different in the 3.1 code base.
I'll decide in the next few weeks.

A somewhat related comment about formatting of infs and nans: I think 
that a formatted nan should never include a sign, even when it's 
explicitly asked for. For example:
"%+e" % float('nan')
should give "nan" rather than "+nan" or "-nan". (In contrast, infinities 
should, and currently do, get the requested sign.)

Here are my proposed tests for this---they're for percent formatting 
rather than format() formatting. They conflict slightly with Daniel's 
tests, in that I think
format(float('inf'), '+')
should produce '+inf' rather than plain 'inf'.

I used 'inf' instead of "+inf' because the original bug report states
that the docs say it should be 'inf'.
Now that I actually look at the docs, I don't agree with the original
report's interpretation and agree that '+inf' is better.

> A somewhat related comment about formatting of infs and nans: I think 
> that a formatted nan should never include a sign, even when it's 
> explicitly asked for.
I'm not so sure about this any more. Sometimes the role of an explicit 
sign is to act as a binary operator or visual separator, when there's 
something immediately preceding the float being formatted. In this case 
one still wants the sign, even for nans.
For example:
>>> "{}{:+}".format(1, float('nan'))
'1+nan'
Also, the implementation is definitely easier this way. :-)

I agree on the alignment issue. Maybe if you explicitly ask for the
"sign" of a NaN, it should always be a space.
And when requesting leading zeros, you also get leading spaces instead?

> Maybe if you explicitly ask for the "sign" of a NaN, it should
> always be a space.
Actually, I think '+nan' for format(float('nan'), '+'), and ' nan'
for format(float('nan'), ' '). Then nans and infs can be treated 
identically, except that the sign of a nan is always considered to be 
positive, regardless of what the _Py_dg_dtoa function returns.
> And when requesting leading zeros, you also get leading spaces
> instead?
Should do the same thing for nans and infs here. But certainly leading 
zeros should be avoided. Leading spaces sounds fine to me.

With the new PyOS_double_to_string, this issue largely goes away. There
are some remaining issues with commas, 'n' and the like. I'll address those.

This patch has tests that currently pass on trunk. I think this is the
desired behavior. I need to augment the tests for format() testing.

Looks good to me, except that the second comment in the patch doesn't make 
a lot of sense any more.

This version adds format() testing and fixes the comments (I hope).

LGTM.

Added tests to trunk in r76632 and py3k in r76634.
Note that the only thing that was changed are the tests. The actual
functionality was fixed earlier when the float formatting was reworked
as part of the short float repr changes.