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.