| msg116413 - (view) |
Author: Eric V. Smith (eric.smith) *  |
Date: 2010-09-14 17:26 |
| 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. |
|
|
| msg116751 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2010-09-18 03:23 |
| 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. |
|
|
| msg130681 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2011-03-12 15:09 |
| 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 |
|
|
| msg130682 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2011-03-12 15:14 |
| Next step is to make it a TypeError in 3.4. |
|
|
| msg149351 - (view) |
Author: Florent Xicluna (flox) * |
Date: 2011-12-12 19:55 |
| Patch is ready for python 3.4 :-) |
|
|
| msg177970 - (view) |
Author: Viktor Ershov (krinart) * |
Date: 2012-12-23 10:28 |
| As I can see this is already implemented in 3.4 |
|
|
| msg177977 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2012-12-23 12:27 |
| 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 |
|
|
| msg177981 - (view) |
Author: Andrew Svetlov (asvetlov) * |
Date: 2012-12-23 12:42 |
| Committed. Thanks. |
|
|
| msg177983 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2012-12-23 13:12 |
| New changeset 2f6ec67636b8 by Andrew Svetlov in branch 'default': Add NEWS and docs for #9856 http://hg.python.org/cpython/rev/2f6ec67636b8 |
|
|
| msg177984 - (view) |
Author: Andrew Svetlov (asvetlov) * |
Date: 2012-12-23 13:19 |
| Updated NEWS and docs |
|
|
| msg177992 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2012-12-23 16:19 |
| 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. |
|
|
| msg177994 - (view) |
Author: Andrew Svetlov (asvetlov) * |
Date: 2012-12-23 16:28 |
| Ok |
|
|
| msg189048 - (view) |
Author: Yogesh Chaudhari (Yogesh.Chaudhari) * |
Date: 2013-05-12 17:06 |
| @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. |
|
|
| msg189049 - (view) |
Author: Yogesh Chaudhari (Yogesh.Chaudhari) * |
Date: 2013-05-12 17:07 |
| Please replace integer.__format__(s) with integer.__format__('') |
|
|
| msg189062 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2013-05-12 20:43 |
| 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 "", line 1, in 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 "", line 1, in 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. |
|
|
| msg189068 - (view) |
Author: Yogesh Chaudhari (Yogesh.Chaudhari) * |
Date: 2013-05-12 22:06 |
| >It's this case that is currently an error, but it need not be: >>>> format(object(), '1') >Traceback (most recent call last): > File "", line 1, in >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 "", line 1, in TypeError: non-empty format string passed to object.__format__ >>> format((1,2,3), '5') Traceback (most recent call last): File "", line 1, in 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. |
|
|
| msg189089 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2013-05-13 02:07 |
| 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. |
|
|
| msg189107 - (view) |
Author: Yogesh Chaudhari (Yogesh.Chaudhari) * |
Date: 2013-05-13 08:32 |
| +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" |
|
|
| msg189586 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2013-05-19 13:11 |
| 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 :) |
|
|
| msg205017 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2013-12-02 15:29 |
| Perhaps the versionchanged tag for format() is more suitable than versionadded. |
|
|
| msg211041 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2014-02-11 23:34 |
| 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 |
|
|