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 mark.dickinson
Recipients eric.smith, mark.dickinson
Date 2009-05-04.11:10:36
SpamBayes Score 0.0
Marked as misclassified No
Message-id <>
I think the change in precision in the following is surprising, and should 
be fixed for 2.7 and 3.1:

Python 3.1a2+ (py3k:72258:72259, May  4 2009, 11:49:27) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '{}'.format(10/3.)
>>> '{:}'.format(10/3.)
>>> '{:13}'.format(10/3.)
'      3.33333'
>>> '{:-}'.format(10/3.)

Notice that the first two results above give 12 digits of precision,
while the third and fourth both give 6 digits of precision.

The above behaviour can be explained by a close reading of PEP 3101.
The last two results come from the section describing the empty 
presentation type for floats:

"""similar to 'g', except that it prints at least one digit after the 
decimal point."""

along with the fact that for 'g', the default precision is 6.  The first 
two results come from this sentence, at the end of the same section:

"""For all built-in types, an empty format specification will produce the 
equivalent of str(value)."""

and the fact that str(float) uses a precision of 12.

To me, it seems wrong, and potentially confusing, that adding a field 
width, or alignment specifier, or sign specifier, all of which have 
nothing to do with precision, should change the precision.

One possible solution would be to have the empty presentation type always 
use a precision of 12.  The output would still be 'similar to 'g'', except 
for the difference in default precision.
Date User Action Args
2009-05-04 11:10:40mark.dickinsonsetrecipients: + mark.dickinson, eric.smith
2009-05-04 11:10:39mark.dickinsonsetmessageid: <>
2009-05-04 11:10:38mark.dickinsonlinkissue5920 messages
2009-05-04 11:10:36mark.dickinsoncreate