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. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "A storm broke loose in my mind." --Albert Einstein
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4