There appears to be most of the formatting options in the *printf 
family... except for the obvious %f. Why is this crucial option missing?

Do you expect to have support for float, double and long double ?
Also, do you expect to have support for precision-modifiers ?

Well, precision modifiers would be nice, but I don't think that they're
necessarily needed. General floating point support, however, is needed.

Attached is a patch attempting to provide support for %f with precision in PyString_FromFormat* based on file Objects/stringobject.c of Python 2.6b1.

Note, only %f is support but %lf is not and silently ignored.

Attached is another patch for file Objects/stringobject.c(relative to 
Python 2.6b1) which supports the double %f and long double %LF formats.  

However, %Lf is included only if symbol  LDBL_DIG is defined in header 
file <float.h> on the underlying platform.

This patch also handles the long and size_t flags correctly in the first 
loop to determine the size of the buffer under
    ...
    case 'd': case 'u': case 'i': case 'x':
    ...

Btw, it does not make sense to handle float since there is not formnat 
specification for floats.

Jean, you can increase *hugely* the possibility of this being accepted
if you submit a comprehensive suite test for this.

Thanks!!

Another rev of the patch now including updates to 2 documentation files: 
Doc/c-api/exceptions.rst and Doc/c-api/string.rst.  As before the patch is 
relative to the source of Python 2.6b1.

Where should test cases for the new formats in the PyString_FromFormat* 
and PyErr_Format functions be added?

The tests for PyString_FromFormat are in file Modules/_testcapimodule.c.

Attached is yet another update of the patch, this one also includes 3 
tests for the new %f format specification added to file 
Modules/_testcapimodule.c.

Here is another patch for PyString_FromFormat* adding support for 'l' and 
'z' type specifications for the '%x' format and an optional '#' to prepend 
'0x' to the hex result.  In addition, the '%p' format is handled as '%#x'.

Updates for the c-api tests and the documentation for exceptions and 
string are also included in the patch.

Like before, the patch is a forward delta to the files of Python 2.6b1.

From the code:

/* assume %f produces at most (L)DBL_DIG 
   digits before and after the decimal
   point, plus the latter plus a sign */

This is not correct. DBL_DIG is 15 on my x86 Linux machine.    
printf("%.*f\n", DBL_DIG, 1e20) produces a string that's 37 characters
long. It might be best to use PyOS_double_to_string instead of snprintf,
although we don't support long double there. I'm not sure long double
support is all that important in practice (for Python), though.

It would be easier to review this if the %p change weren't also
included. That's looks like a good change, but it's a separate issue.

unicodeobject.c should also be modified. In 3.x, it's unicodeobject.c
and bytesobject.c that need to work.

I also think it would be good to use PyOS_double_to_string here.  That
does make it impossible to format long doubles, though, except by doing
a possibly lossy conversion to double first.

As far as I can see, Python doesn't use long double anywhere outside the
ctypes module, so I'm not sure that long double support really matters
right now.

Jean, do you intend taking this issue any further or can it be closed?

I'll take a look at this.

Mark L,

No, I do not intend to take this issue further.  Rather the opposite, it should probably be paired down based on the recent comments.  Specifically, use PyOS_double_to_string, remove support for long double and perhaps more.

Also, the patches I created are more than 2 years old and will need to be updated against the current stringobject.c code.  There are quite a few changes in the 2.7 version of that file since early 2.6.

Closing as Jean has no interest in keeping it open.

Jean may have no interest in moving this forward, but I do.  (Which is why I assigned the issue to me.)

Okay, I've failed to take this forward.  Reclosing as out of date.