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 bpo-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':
bpo-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 bpo-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 bpo-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