2010/8/5 Fred Drake <fdr...@acm.org>: > 2010/8/4 Łukasz Langa <luk...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
