Am 20.05.2013 17:39, schrieb Steven D'Aprano:
On 21/05/13 00:12, Ethan Furman wrote:
As a case in point, base64.py is currently getting a bug fix, and also contains this code:
def b32decode(s, casefold=False, map01=None): . . . for i in range(0, len(s), 8): quanta = s[i: i + 8] acc = 0 try: for c in quanta: acc = (acc << 5) + b32rev[c] except KeyError: raise binascii.Error('Non-base32 digit found') . . . else: raise binascii.Error('Incorrect padding')
Does the KeyError qualify as irrelevant noise?
IMO, it is irrelevant noise, and obviously so. The binascii.Error raised is not a bug to be fixed, it is a deliberate exception and part of the API of the binascii module. That it occurs inside an "except KeyError" block is a mere implementation detail. It merely happens to be that digits are converted by looking up in a mapping, another implementation might use a completely different mechanism. In fact, the implementation in Python 3.3 *is* completely different, and there is no KeyError to suppress.
In another reply, R.David Murray answered:
"I don't see that it is of benefit to suppress [the KeyError]."
Can I suggest that it's obviously been a long, long time since you were a beginner to the language, and you've forgotten how intimidating error messages can be? Error messages should be *relevant*. Irrelevant details don't help, they hinder, and I suggest that the KeyError is irrelevant.
I agree. This is a case of a well isolated exception where there's no chance of hiding a bug because the KeyError was exceptional (<wink/>). The argument of not making it harder than necessary to beginners (or casual users) seems valid to me, and since the code is being touched anyway, there shouldn't be unnecessary code churn. Georg