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

[Łukasz Langa]

Wiadomość napisana przez Nick Coghlan w dniu 2010-08-04, o godz. 23:57:

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

So I'm proposing to close the original issue #2651 and not include what's there.
(see below though)

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

Good stuff guys. Shall we do an e.index for IndexErrors as well?

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

I'm -1 because we would alter the standard library to use this functionality
which would make it incompatible with other implementations. That is of
course unless Guido says we should add it anyway ;)

We might create a separate issue superseding #2651 which will be all about
presenting sensible named arguments for built-in exceptions. Does this sound
like a good plan?

-- 
Best regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100805/a47d8dc6/attachment.html>