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.

Here's a patch, that also changed complex formatting in the same way.

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.

> 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.

> 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.

> ... so I'd prefer to remove 's' and use 'g' with a specified precision.
Let's do that then.  I'll update the patch.

Updated patch, that removes the 's' type code.

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.

Committed in py3k r72333 and trunk r72348. I also updated the
documentation. Closing the issue.

messages: + msg87267
components: + Interpreter Core

messages: + msg87229

stage: needs patch -> patch review