Terry J. Reedy added the comment:
I see now that my expectation, based on decimal rounding rather than binary
conversion and rounding, was wrong ;-)
>>> 33.14159265358979323846264338327950288419 == 33.1415926535898
True
>>> 33.14159265358979323846264338327950288419 == 33.14159265358979
False
>>> format(33.14159265358979323846264338327950288419, '.18')
'33.1415926535897967'
Tommy: 3.3 only gets security fixes. When a core developer (indicated by the
blue and yellow snake symbol) resets Versions, you should leave them alone or
ask before changing.
As for the patch: 'non-scientific' == 'fixed-point', the expression already
used in the table. The rewrite omits the fact the exception is to match str and
that g and str are otherwise the same except for fixed versus 'as needed'
precision. I note that '' = 'd' for integers also makes '' for integers
similar to str() as modified by the preceding options. An alternate rewrite:
Similar to 'g', except that fixed-point notation, when used, has at least one
digit past the decimal point. The default precision is as high as needed to
represent the particular value. The overall effect is to match the output of
str() as altered by the other format modifiers.
--
The following in the examples could be fixed in the same patch
>>> '{:+f}; {:+f}'.format(3.14, -3.14) # show it always
'+3.140000; -3.140000'
add to the comment 'it always displays a sign'.
----------
versions: -Python 3.3
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22546>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
