| msg87114 - (view) |
Author: Mark Dickinson (mark.dickinson) *  |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2009-05-05 08:56 |
| Updated patch, that removes the 's' type code. |
|
|
| msg87242 - (view) |
Author: Eric V. Smith (eric.smith) * |
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) * |
Date: 2009-05-05 18:27 |
| Committed in py3k r72333 and trunk r72348. I also updated the documentation. Closing the issue. |
|
|