homepage

In 3.3 the existing PendingDeprecationWarning needs to become a DeprecationWarning. In 3.4 it will become an error.
I'll change 3.3 after 3.2 is released.
See issue 7994 for the original PendingDeprecationWarning discussion.

Perhaps this could be expanded to "Deprecation warnings in 3.3" with release-blocker priority to list all 3.2 PendingDWs. Once changes are made, it could be retitled "Removals in 3.4", with a new "Deprecation warnings in 3.4" added.

New changeset ee259a4f3eee by Eric V. Smith in branch 'default':
Issue 9856: Change object.__format__ with a non-empty format string from a PendingDeprecationWarning to a DeprecationWarning.
http://hg.python.org/cpython/rev/ee259a4f3eee 

Next step is to make it a TypeError in 3.4.

Patch is ready for python 3.4
:-)

As I can see this is already implemented in 3.4

New changeset d91c14788729 by Andrew Svetlov in branch 'default':
Issue #9856: Replace deprecation warinigs to raising TypeError in object.__format__
http://hg.python.org/cpython/rev/d91c14788729 

Committed. Thanks.

New changeset 2f6ec67636b8 by Andrew Svetlov in branch 'default':
Add NEWS and docs for #9856
http://hg.python.org/cpython/rev/2f6ec67636b8 

Updated NEWS and docs

The more I think about this, the more overly restrictive I realize it is. If the type of the object really is "object", then it can use string formatting. It's only for non-objects that I want to add the error.
I'll re-open it and give it some more thought.

Ok

@Eric:
when you say: "If the type of the object really is "object", then it can use string formatting. It's only for non-objects that I want to add the error.". 
I am confused. Let me demonstrate what I'm thinking according to the statement above. 
First let us take a 'non-object':
>>> integer=1
>>> type(integer) != object
True
As of now it returns the following:
>>> integer.__format__(s)
'1'
Which seems natural.
But after this patch should it return an error
Also now consider an object:
>>> f = object()
>>> type(f)
<class 'object'>
This will return the following after the patch as it does now which is:
>>> f.__format__('')
'<object object at 0xb75b7b48>'
Does this mean that 'integer' should give an error, however, 'f' should give something that appears messy?
I may be mistaken in my interpretation of the statement, so kindly let me know if there is something else that I am not clearly understanding.

Please replace 
integer.__format__(s)
with 
integer.__format__('')

But int has its own __format__ method, so this does not apply. Per the title of this issue, this only refers to object.__format__.
For example:
This works now, and will continue working:
>>> format(2, '1')
'2'
This is currently an error, and will remain an error:
>>> class C: pass
...
>>> format(C(), '1')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__
It's this case that is currently an error, but it need not be:
>>> format(object(), '1')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__
The more I think about it, the more I think it would be too confusing to make object.__format__ behave differently if self is of type object, versus another type. So I'll probably just close this as fixed unless someone feels strongly about it.

>It's this case that is currently an error, but it need not be:
>>>> format(object(), '1')
>Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
>TypeError: non-empty format string passed to object.__format__
I believe that should continue to remain an error. Please note that this works
>>> format(object(), '')
'<object object at 0xb74fd688>'
From what I can tell, specifying '1' or '2' or '100' makes no sense because unlike string or int (and like list or tuple ) this 'number' does not represent anything sensible.
This works fine as it should:
>>> format('q', '5')
'q '
>>> format(1, '5')
' 1'
>>> format(1, '05')
'00001'
>>> 
But this does not and IMHO *should* not 'work'
>>> format([1,2,3], '5')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__
>>> format((1,2,3), '5')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__
an object() CANNOT have specific behavior like str or int. You can of-course argue as to what kind of error/exception/warning this may raise, but it does not make any sense (AFAIK) to 'fix' this.

Everying is an instance of object. If its class does not override .__format__, then it seems that it should act the same as a direct object instance. If this a the current plan (or patch already committed, I think I would stay with that.

+1 to Terry for "If its class does not override .__format__, then it seems that it should act the same as a direct object instance"

Since Eric indicated he'd close this unless someone felt strongly that the status quo should be changed, and the arguments are in favor of *maintaining* the status quo, I'm going to close this for him :)

Perhaps the versionchanged tag for format() is more suitable than versionadded.

New changeset f56b98143792 by R David Murray in branch 'default':
whatsnew: object.__format__ raises TypeError on non-empty string.
http://hg.python.org/cpython/rev/f56b98143792