Wiadomość napisana przez Nick Coghlan w dniu 2010-08-04, o godz. 23:57:
2010/8/5 Fred Drake <fdrake@acm.org>:
2010/8/4 Łukasz Langa <lukasz@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/