| msg119778 - (view) |
Author: Dirkjan Ochtman (djc) *  |
Date: 2010-10-28 13:26 |
| djc@miles ~ $ python2.7 Python 2.7 (r27:82500, Oct 4 2010, 10:01:41) [GCC 4.3.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> {}.pop('a') Traceback (most recent call last): File "", line 1, in KeyError: 'pop(): dictionary is empty' >>> {'a': 'b'}.pop('c') Traceback (most recent call last): File "", line 1, in KeyError: 'c' IMO the former exception should be in line with normal KeyErrors. |
|
|
| msg119796 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2010-10-28 15:44 |
| There have been several requests for KeyError to grow "key" attribute that will always contain the key that caused the error. See issue 1182143, for example. If this is done, I think it would be natural to unify the args as well for empty and non-empy case. Without adding key access API, however, I am at most -0 on changing the error message. Traditionally, the error messages are not considered part of language specification, so this is not a bug. |
|
|
| msg119802 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2010-10-28 16:37 |
| I agree with the OP's request. d.pop(k) is conceptually equivalent to: r = d[k] # raises KeyError(k) del d[k] return r The current message was probably borrowed from dict.popitem(). But that is much different since the dict.pop(k) method is key-specific (instead of size related). This fix should be backported (as it doesn't change guaranteed behaviors but does improve the debugability). |
|
|
| msg119803 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2010-10-28 16:55 |
| This is the case where fixing an issue is easier than arguing that it is not a bug. :-) (Changing to "behavior" not because I agree that it is a bug, but for consistency with targeting 2.7) A (1-line) patch attached. |
|
|
| msg119804 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2010-10-28 17:07 |
| Attaching a patch with tests. |
|
|
| msg119805 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2010-10-28 17:21 |
| I wonder if it would be worthwhile to unify missing key processing as in issue10221a-with-tests.diff. |
|
|
| msg119966 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2010-10-30 08:18 |
| See r85967, r85968 and r85969. |
|
|
| msg120147 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2010-11-01 18:00 |
| Raymond, Did you mean to exclude unit test additions from your commit? See -with-tests.diff. |
|
|
| msg120150 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2010-11-01 18:13 |
| We don't usually test the content of error messages because they are not a guaranteed behavior. |
|
|
| msg120152 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2010-11-01 18:29 |
| On Mon, Nov 1, 2010 at 2:13 PM, Raymond Hettinger <report@bugs.python.org> wrote: .. > > We don't usually test the content of error messages because they are not a guaranteed behavior. > I recall that when I asked about this on #python-dev, someone pointed to places where content of error messages is tested in python unit tests. I also asked whether such tests should be marked as cpython details, and the answer was know. Unfortunately I don't remember who was telling me that, but it sounded reasonable enough that I submitted the tests. I think if testing error messages is a grey area, in this case it is reasonable to have a test for at least two reasons: 1. It was reported as a bug, so users already expect this behavior. 2. There is no prose in the error message, just the key, so it is not as arbitrary as other error messages. Note that in my tests I deliberately tested only e.args[0] and not str(e) or e.args[1:]. |
|
|