[Python-Dev] PEP 409 and the stdlib

Ethan Furman ethan at stoneleaf.us
Mon May 20 17:15:08 CEST 2013


On 05/20/2013 07:50 AM, R. David Murray wrote:
> On Mon, 20 May 2013 07:12:07 -0700, 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?
>
> I don't see that it is of benefit to suppress it.
>
>> If we're not going to suppress the originating error I think we should
>> at least change the double trace back message as it implies two
>> failures, instead of just one.
>
> I don't understand what you want to do here.

As a user of the b32decode the KeyError is an implementation detail and noise in the traceback.  If I've got a 
non-base32 digit in my submitted string then the only exception I care about is the binascii.Error... but I'm going to 
see both, and the wording is such that it seems like I have two errors to deal with instead of just one.

So I guess I see three options here:

1)  Do nothing and be happy I use 'raise ... from None' in my own libraries

2)  Change the wording of 'During handling of the above exception, another exception occurred' (no ideas as to what at 
the moment)

3)  have the traceback module be configurable to show both exceptions even when 'raise ... from None' is used to help 
with debugging, then we can make the changes in stdlib confident that in our own testing of bugs we can see all 
available information.

I would prefer 3, but I can live with 1.  :)

--
~Ethan~


More information about the Python-Dev mailing list