[Python-Dev] PEP 3101: floats format 'f' and 'F'

[Guido van Rossum]

On Wed, Jul 16, 2008 at 7:52 PM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
> Mark Dickinson wrote:
>>
>> On Wed, Jul 16, 2008 at 4:15 PM, Eric Smith
>> <eric+python-dev at trueblade.com> wrote:
>>>
>>> There's no exponent until the number gets large.  I haven't looked up how
>>> big the number has to get.  On my Mac, it's somewhere between 1e50 and
>>> 1e60.
>>
>> I think it's around 1e50, courtesy of the rather oddly-phrased line in
>> unicodeobject.c
>> (this is in py3k) that looks like:
>>
>>    if (type == 'f' && (fabs(x) / 1e25) >= 1e25)
>
> I don't know why that test exists.  It comes from Guido in r3417
> (1993-03-16!).  It's from the very first incarnation of formatfloat().
>
> I'd like to remove it, but there's no telling what it would break. Surely
> something written in the last 15+ years depends on it.  But if it were
> removed, then (as Tim points out) only INF and NAN would be in uppercase for
> 'F'.
>
> regrtest.py still works with it removed, except for string_tests.py, which
> is explicitly looking for this behavior, and has this comment:
>            # The formatfloat() code in stringobject.c and
>            # unicodeobject.c uses a 120 byte buffer and switches from
>            # 'f' formatting to 'g' at precision 50, so we expect
>            # OverflowErrors for the ranges x < 50 and prec >= 67.
>
> The fixed size buffer could be dealt with, but it doesn't seem worth it
> given the potential breakage.
>
> For now, I'll just make 'F' convert to uppercase, and leave the 1e50 issue
> for another release.

It was an attempt to prevent ridiculously long output, with lots of
nonsensical digits suggesting precision that isn't there. Since nobody
in their right mind should use %f for such large numbers anyway,
removing it shouldn't hurt anything, but it might startle users who
try things at the interactive prompt, or who simply have a bug in
their code causing oversized numbers to be produced. So my
recommendation would be to leave it in.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)