classification
Title: Confusing float formatting for empty presentation type.
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.1, Python 2.7
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: eric.smith Nosy List: eric.smith, mark.dickinson
Priority: normal Keywords: patch

Created on 2009-05-04 11:10 by mark.dickinson, last changed 2009-05-05 18:27 by eric.smith. This issue is now closed.

Files
File name Uploaded Description Edit
issue5920.patch mark.dickinson, 2009-05-04 11:35
issue5920_v2.patch mark.dickinson, 2009-05-05 08:56
Messages (9)
msg87114 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-05-04 11:10
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.
msg87115 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-05-04 11:35
Here's a patch, that also changed complex formatting in the same way.
msg87148 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-05-04 18:49
About your patch: Wouldn't it make more sense to switch to type 's',
with a precision of 0, so as to use the same logic that float_str uses?
I realize it's the same result, but if we're making the point that we
want to match float_str, it makes sense to me to use the same logic so
you don't have to walk through the code to figure it out.

Or, also switch float_str to use 'g' with a precision of
PyFloat_STR_PRECISION, and get rid of 's' altogether. But maybe we
should do that as a separate step, after this change.
msg87155 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-05-04 19:30
> Wouldn't it make more sense to switch to type 's',
> with a precision of 0, so as to use the same logic that float_str 
uses?

Yes, that makes some sense.  How would you handle 
'{:.10}'.format(10/3.), though?  We could either change 's' to allow a 
precision, or use 's' when there's no precision specified and 'g' (with 
the ADD_DOT_0 flag) otherwise.

> Or, also switch float_str to use 'g' with a precision of
> PyFloat_STR_PRECISION, and get rid of 's' altogether.

This sounds good to me.  It does feel as though there's unnecessary
duplication with the current setup.
msg87165 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-05-04 20:20
> Yes, that makes some sense.  How would you handle 
> '{:.10}'.format(10/3.), though?  We could either change 's' to allow a 
> precision, or use 's' when there's no precision specified and 'g' (with 
> the ADD_DOT_0 flag) otherwise.

Good point, I hadn't thought of that. I'm not a big fan of switching 
between 's' and 'g' depending on whether a precision is specified.

>> Or, also switch float_str to use 'g' with a precision of
>> PyFloat_STR_PRECISION, and get rid of 's' altogether.
> 
> This sounds good to me.  It does feel as though there's unnecessary
> duplication with the current setup.

A major point of 's' was to not specify the precision, so I'd prefer to 
remove 's' and use 'g' with a specified precision.
msg87170 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-05-04 20:46
> ... so I'd prefer to remove 's' and use 'g' with a specified precision.

Let's do that then.  I'll update the patch.
msg87229 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-05-05 08:56
Updated patch, that removes the 's' type code.
msg87242 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-05-05 12:31
I've reviewed this and it looks good. I'll check it in to py3k shortly.
Then I'll backport it to 2.7 and fix the user documentation.
msg87267 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-05-05 18:27
Committed in py3k r72333 and trunk r72348. I also updated the
documentation. Closing the issue.
History
Date User Action Args
2009-05-05 18:27:46eric.smithsetstatus: open -> closed

messages: + msg87267
components: + Interpreter Core
2009-05-05 12:31:38eric.smithsetresolution: accepted
messages: + msg87242
stage: patch review ->
2009-05-05 08:56:47mark.dickinsonsetfiles: + issue5920_v2.patch

messages: + msg87229
2009-05-04 20:46:34mark.dickinsonsetmessages: + msg87170
2009-05-04 20:20:55eric.smithsetmessages: + msg87165
2009-05-04 19:30:15mark.dickinsonsetmessages: + msg87155
2009-05-04 18:49:08eric.smithsetmessages: + msg87148
2009-05-04 11:35:51mark.dickinsonsetfiles: + issue5920.patch
keywords: + patch
messages: + msg87115

stage: needs patch -> patch review
2009-05-04 11:10:38mark.dickinsoncreate