Change object.__format__(s) where s is non-empty to a TypeError

[ericvsmith]

BPO	9856
Nosy	@terryjreedy, @ericvsmith, @bitdancer, @asvetlov, @florentx, @serhiy-storchaka
Files	issue9856_python-3.4.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ericvsmith'
closed_at = <Date 2013-05-19.13:11:53.900>
created_at = <Date 2010-09-14.17:26:57.550>
labels = ['interpreter-core', 'easy', 'deferred-blocker', 'type-bug']
title = 'Change object.__format__(s) where s is non-empty to a TypeError'
updated_at = <Date 2014-02-11.23:34:43.381>
user = 'https://github.com/ericvsmith'

bugs.python.org fields:

activity = <Date 2014-02-11.23:34:43.381>
actor = 'python-dev'
assignee = 'eric.smith'
closed = True
closed_date = <Date 2013-05-19.13:11:53.900>
closer = 'r.david.murray'
components = ['Interpreter Core']
creation = <Date 2010-09-14.17:26:57.550>
creator = 'eric.smith'
dependencies = []
files = ['23936']
hgrepos = []
issue_num = 9856
keywords = ['patch', 'easy']
message_count = 21.0
messages = ['116413', '116751', '130681', '130682', '149351', '177970', '177977', '177981', '177983', '177984', '177992', '177994', '189048', '189049', '189062', '189068', '189089', '189107', '189586', '205017', '211041']
nosy_count = 11.0
nosy_names = ['terry.reedy', 'eric.smith', 'Arfrever', 'r.david.murray', 'asvetlov', 'flox', 'python-dev', 'serhiy.storchaka', 'krinart', 'Ankur.Ankan', 'Yogesh.Chaudhari']
pr_nums = []
priority = 'deferred blocker'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue9856'
versions = ['Python 3.4']

[ericvsmith]

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.

[terryjreedy]

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.

[python-dev]

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

[ericvsmith]

Next step is to make it a TypeError in 3.4.

[florentx]

Patch is ready for python 3.4

:-)

[krinart]

As I can see this is already implemented in 3.4

[python-dev]

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

[asvetlov]

Committed. Thanks.

[python-dev]

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

[asvetlov]

Updated NEWS and docs

[ericvsmith]

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.

[asvetlov]

Ok

[YogeshChaudhari]

@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.

[YogeshChaudhari]

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

[ericvsmith]

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.

[YogeshChaudhari]

>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.

[terryjreedy]

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.

[YogeshChaudhari]

+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"

[bitdancer]

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 :)

[serhiy-storchaka]

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

[python-dev]

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