This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients Barium, docs@python, eric.smith, mark.dickinson, terry.reedy
Date 2014-10-04.23:53:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I see now that my expectation, based on decimal rounding rather than binary conversion and rounding, was wrong ;-)
>>> 33.14159265358979323846264338327950288419 == 33.1415926535898
>>> 33.14159265358979323846264338327950288419 == 33.14159265358979
>>> format(33.14159265358979323846264338327950288419, '.18')

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'.
Date User Action Args
2014-10-04 23:53:46terry.reedysetrecipients: + terry.reedy, mark.dickinson, eric.smith, docs@python, Barium
2014-10-04 23:53:46terry.reedysetmessageid: <>
2014-10-04 23:53:46terry.reedylinkissue22546 messages
2014-10-04 23:53:46terry.reedycreate