[issue18163] Add a 'key' attribute to KeyError

[Andre Roberge]

Change by Andre Roberge :


--
nosy: +aroberge

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Mark Dickinson]

Change by Mark Dickinson :


--
nosy:  -mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Stéphane Blondon]

Stéphane Blondon  added the comment:

I'm interested by such feature.

I see examples of versions of the message provided by KeyError:
- sometimes with a message (for example `PyErr_SetString(PyExc_KeyError, "name 
too long");` at [1])
- sometimes with the missing key (for example `PyErr_SetObject(PyExc_KeyError, 
key);` at [2])

It explains why there is a difference in the messages in KeyError (as said in 
previous messages).

PyErr_SetString(), PyErr_Format(), PyErr_FormatV() (implemented in 
Python/errors.c) don't have a parameter to set the missing key. So I think it 
would be easier to set the missing attribute before calling thoses functions.


According to [3], the C PyExc_KeyError matches the Python KeyError exception.

So I think to:
- Add a 'missing_key' attribute to KeyError_str (in [4])
- Add the missing key to PyExc_KeyError instance before the call of 
PyErr_SetString(), PyErr_SetObject(), etc.

Do you think such strategy is doable?
What do you think about it? Is it the way you think about it? If not, do you 
have some hint?


I already made some minor patches to cpython but only in the Python part, never 
in C one.


1: https://github.com/python/cpython/blob/master/Modules/unicodedata.c#L1398
2: https://github.com/python/cpython/blob/master/Python/hamt.c#L2767
3: 
https://docs.python.org/3/c-api/exceptions.html?highlight=pyerr_format#standard-exceptions
4: https://github.com/python/cpython/blob/master/Objects/exceptions.c#L1569

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Stéphane Blondon]

Stéphane Blondon  added the comment:

Orian: your patch formats the error message but the original suggested  
solution is to store the missing key in a new attribute. 

I don't know if you go in the good direction.

Adding an attribute is also suggested by issue #614557.

--
nosy: +sblondon
versions:  -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Anatoliy Platonov]

Anatoliy Platonov  added the comment:

I agree with Mark. I will be useful to provide ability to specify custom long 
message for error. And logically it would be better to do not allow users 
change key field in error so easy.

--
nosy: +p4m-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Orian Zinger]

Change by Orian Zinger :


--
components:  -Library (Lib)

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Orian Zinger]

Orian Zinger  added the comment:

Hi all,

As a Python developer, I encountered lots of blurry exception messages in the 
product logs such as:
   Failed to do something. 
Exception: 'some key'

I believe printing the key name without explaining the exception itself is bad 
(explicit is better than implicit).

Thus, after forking the repository, I added a short explanation about the 
Exception.
Now, it looks like:

>>> try:
... {}['some key']
... except Exception as e:
... print(e)
... 
Missing key: some key

I'm a newbie in a contribution to CPython, so please let me know if the idea 
behind my commit is good. If not, please explain how can I improve my commit so 
it'll be pulled later to the main branch.

https://github.com/zingero/cpython/commit/8c9e5d9e16296cee1f3ec05638dd6989dae8b811

Regards,
Orian.

--
components: +Library (Lib) -Interpreter Core
nosy: +zingero

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Ezio Melotti]

Changes by Ezio Melotti ezio.melo...@gmail.com:


--
nosy: +ezio.melotti

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18163
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Chris Rebert]

Changes by Chris Rebert pyb...@rebertia.com:


--
nosy: +cvrebert

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18163
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Mark Dickinson]

Mark Dickinson added the comment:

+1.  I recently chastised a colleague for doing raise KeyError(long_message) 
instead of raise KeyError(missing_item).  When I went to the standard library 
to support my POV, I found (to my chagrin) a big mix of the two styles.


 from collections import ChainMap
 d = ChainMap({}, {})
 try:
... d.pop('not there')
... except KeyError as e:
... key, = e.args
... 
 key
Key not found in the first mapping: 'not there'

--
nosy: +mark.dickinson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18163
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Brett Cannon]

Brett Cannon added the comment:

What David said. =)

The fact that the key is the first value from args is almost happenstance as 
the exception message is customized in __str__() and not in what is passed to 
the exception. But what if I had defined __getattr__ or __getattribute__ and 
had some prefix requirement? It would be more helpful to say ``KeyError({!r} 
does not start with py_.format(key))`` which breaks your args[0] usage but is 
a much more descriptive message and has no defined way to provide the key as an 
attribute.

It's basically explicit is better than implicit since there is no API 
guarantee that the first thing in 'args' for KeyError will in actuality be the 
key.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18163
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Raymond Hettinger]

Raymond Hettinger added the comment:

Since the key is already accessible via the args attribute, what is the point 
of a new attribute?

 d = {}
 try:
d['roger']
except KeyError as e:
print(e.args)


('roger',)

--
nosy: +rhettinger

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18163
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[R. David Murray]

R. David Murray added the comment:

Making it unambiguous what piece of data is being retrieved, and allowing new 
code to have a more complex message than just 'Keyerror: ' and still be 
able to get at only the missing key.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18163
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Brett Cannon]

New submission from Brett Cannon:

KeyError could grow a 'key' attribute for the key that triggered the exception. 
Since keys are expected to be immutable (in order to be hashable) there is no 
GC issue to worry about.

--
components: Interpreter Core
messages: 190778
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Add a 'key' attribute to KeyError
type: enhancement
versions: Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18163
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[R. David Murray]

R. David Murray added the comment:

I don't see how the fact that keys are immutable implies there are no GC 
issues.  A tuple can be involved in a cycle, for example.

--
nosy: +r.david.murray

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18163
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Barry A. Warsaw]

Changes by Barry A. Warsaw ba...@python.org:


--
nosy: +barry

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18163
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[Brett Cannon]

Brett Cannon added the comment:

So are you arguing it should be a weakref, or just saying you view the 
statement as false?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18163
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18163] Add a 'key' attribute to KeyError

[R. David Murray]

R. David Murray added the comment:

I'm arguing that the statement is false.  I think that whether or not it should 
be a weakref in this and the other cases depends on whether you think an 
exception object should keep an object alive or not.  It is fairly unlikely 
that a key would get into a cycle with an error message, though certainly not 
impossible.

The keep alive question probably boils down to whether or not we want it to 
be the case that clearing the traceback attribute releases all the extra 
pointers an exception holds on to, or if it is acceptable that an arbitrary 
number of additional attributes might do so.

I'm inclined to think that using weakrefs would make using the attributes more 
complicated for relatively little gain.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18163
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com