See http://mail.python.org/pipermail/python-dev/2008-July/081242.html
for the discussion.  Basically, 'F' did the same as 'f' because it was
assumed that neither would ever produce an exponent.  But they do, for
numbers greater than about 1e50.  Also, 'F' should produce 'NAN' for
cases where 'f' produces 'nan'.

Implemented for trunk in r65069; for py3k in r65073.

Changes backed out, pending fixing on Windows.

Unfortunately, I missed the window to get these into 3.0 and 2.6.
Better luck for 3.1 and 2.7!

If http://bugs.python.org/issue5859 is implemented, then this issue
really just becomes making sure NAN and INF are uppercase.

With the implementation of issue5859 (py3k only), the only case where
this matters in NAN and INF. I'm going to address those in 3.1, and not
make any change for 2.x.

Checked in to py3k in 72398. I'm reconsidering whether to make this
change in 2.7. I might make the change there, I'll have to check on the
impacts.

Eric, any further thoughts about making this change in 2.7?  Here's a
patch that does it (I think).

Thanks for looking at this, Mark.
Your patch looks okay to me, but Objects/stringlib/formatter.h still has
some 'F' -> 'f' logic in it, although it turns out that it's wrong:
#if PY_VERSION_HEX < 0x0301000
    /* 'F' is the same as 'f', per the PEP */
    /* This is no longer the case in 3.x */
    if (type == 'F')
        type = 'f';
#endif
Note that it's missing a zero on the end, so this code is never (and I
guess never was) executed. I'll remove it and add a test.
It also looks like complex is still mapping 'F' to 'f'. I'll fix that,
too, and add a test for it.
Thanks again.

Here's a patch which adds some tests and fixes complex.
I'm currently testing with PY_NO_SHORT_FLOAT_REPR on Windows. If that's
okay, and if you don't have any objections, I'll commit this. While I'm
at it I'll modify Objects/stringlib/formatter.h in py3k to keep them it
sync with trunk.

Looks good to me.

Committed (with a few more tests) in r76583.

stage: resolved

messages: + msg95807