Background:

format(obj, fmt) eventually calls object.__format__(obj, fmt) if obj (or one of its bases) does not implement __format__. The behavior of object.__format__ is basically:

def __format__(self, fmt):
    return str(self).__format__(fmt)

So the caller of format() thought they were passing in a format string specific to obj, but it is interpreted as a format string for str.

This is not correct, or at least confusing. The format string is supposed to be type specific. However in this case the object is being changed (to type str), but the format string which was to be applied to its original type is now being passed to str.

This is an actual problem that occurred in the migration from 3.0 -> 3.1 and from 2.6 -> 2.7 with complex. In the earlier versions, complex did not have a __format__ method, but it does in the latter versions. So this code:
>>> format(1+1j, '10s')
'(1+1j)    '
worked in 2.6 and 3.0, but gives an error in 2.7 and 3.1:
>>> format(1+1j, '10s')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 's' for object of type 'complex'

Proposal:
object.__format__ should give an error if a non-empty format string is specified. In 2.7 and 3.2 make this a PendingDeprecationWarning, in 3.3 make it a DeprecationWarning, and in 3.4 make it an error.

Modify the documentation to make this behavior clear, and let the user know that if they want this behavior they should say:

format(str(obj), '10s')

or the equivalent:

"{0!s:10}".format(obj)

That is, the conversion to str should be explicit.

Proposed patch attached. I need to add tests and docs.

issue7994-0.diff is against trunk.

This version of the patch adds support for classic classes and adds tests. Documentation still needs to be written.

Again, this diff is against trunk.

If anyone wants to review this, in particular the tests that exercise PendingDeprecationWarning, that would be great.

Patch with Misc/NEWS.

The patch looks reasonable.  I built on it with the following changes:

   1. Added some extra test cases to cover Unicode format strings, 
      since the code was changed to handle these as well.
   2. Changed test_builtin.py by 
      s/m[0].message.message/str(w[0].message)/, since 
      BaseException.message was deprecated in 2.6.

I also have the following general comments:

   1. PEP 3101 explicitly defines the string conversion for 
      object.__format__.  What is the rationale behind this?  Should
      we find out before making this change?
   2. I don't think the comments in 'abstract.c' and 'typeobject.c'
      explaining that the warning will eventually become an error are
      needed.  I think it would be better to open separate issues for
      these migration steps as they can be tracked easier and will be 
      more visible.
   3. test_unicode, test_str have cases that trigger the added 
      warning.  Should they be altered now or when (if) this becomes 
      an error?

I haven't looked at the patch, but:

Thanks for the the additional tests. Missing unicode was definitely a mistake.

str(w[0].message) is an improvement.

The PEP is out of date in many respects. I think it's best to note that in the PEP and continue to keep the documentation up-to-date.

This issue already applies to 3.3, but my plan is to remove that and create a new issue when I close this one. But I'd still like to leave the comments in place.

I'm aware of the existing tests which trigger the warning. I think they should probably be removed, although I haven't really spent much time thinking about it.

Meador: Your patch (-3) looks identical to mine (-2), unless I'm making some mistake. Could you check? I'd like to get this applied in the next few days, before 2.7b1.

Thanks!

Hi Eric,

(-2) and (-3) are different.  The changes that I made, however, are pretty minor.  Also, they are all in 'test_builtin.py'.

Committed in trunk in r79596. I'll leave this open until I port to py3k, check the old tests for this usage, and create the issue to make it a DeprecationWarning.

This should be merged before 3.2 beta.

now the PendingDeprecationWarnings are checked in the test suite, with r84772 (for 2.7).

Manually merged to py3k in r84790. I'll leave this open until I create the 3.3 issue to change it to a DeprecationWarning.

See issue 9856 for changing this to a DeprecationWarning in 3.3.