New submission from Mark Dickinson <dicki...@gmail.com>:
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.)
'3.33333333333'
>>> '{:}'.format(10/3.)
'3.33333333333'
>>> '{:13}'.format(10/3.)
' 3.33333'
>>> '{:-}'.format(10/3.)
'3.33333'
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.
----------
assignee: eric.smith
messages: 87114
nosy: eric.smith, marketdickinson
severity: normal
stage: needs patch
status: open
title: Confusing float formatting for empty presentation type.
type: behavior
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5920>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
