[Python-Dev] #2651 - KeyError does not round trip strings

[Nick Coghlan]

2010/8/5 Fred Drake <fdrake at acm.org>:
> 2010/8/4 Łukasz Langa <lukasz at langa.pl>:
>> 1. The patch makes KeyError behave analogically to IOError so that the first
>> arg is now a message and the second is the actual key.
>
> I agree with Antoine; there's no point to this.
>
>> 2. Some people suggest adding e.key to KeyError. I like the idea but in my
>> opinion currently it is not implementable in a reliable way.
>
> This is interesting and useful.
>
> I'd be really happy to see e.key be present if the key is known
> (because it was specifically provided to the constructor:
> KeyError(key=...)), or not present if the key isn't known.  (The idea
> is much less interesting if code can't distinguish between the
> key-is-known and the key-not-known cases.)
>
> The runtime and standard library should be adjusted to provide the key
> whenever possible, of course.
>
> Though I doubt this would break anything, we've lived without this
> long enough that the it doesn't represent a sufficient failing that
> the moratorium should be broken.  It can wait.

+1 on what Fred said (i.e. post-moratorium, add a keyword-only "key"
argument to KeyError, set "e.key" only if that argument is supplied,
update the standard library to supply it and use a default message of
"'Key not found: %r' % key" if the key argument is supplied without an
explicit message). Also +1 for doing the equivalent with
AttributeError and an "attr" keyword only argument.

Since a keyword-only approach doesn't actually *break* any current
code, I'm only -0 on doing that for 3.2 rather than -1.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia