Does any code parse the PEP 376 digests in RECORD?

Any objections if I edit PEP 376 to remove the "unnamed hexdigest is md5" leaving only algname=base64-digest?

On Fri, Oct 26, 2012 at 12:28 PM, Daniel Holth <> wrote:
On Fri, Oct 26, 2012 at 4:11 AM, Paul Moore <> wrote:
> On 26 October 2012 08:54, Ronald Oussoren <> wrote:
>>> It's nice and small. The encoder is just
>>> base64.urlsafe_b64encode(digest).rstrip('=')
>> But is the size difference really important? The wheel file itself is compressed, and the additional
>> amount of space needed on installation shouldn't be a problem.  The advantage of using hexdigest
>> is that both the "classic" MD5 checksum and the new tagged checksums you propose then use
>> the same encoding for the signature.
> I agree. This encoding seems to be a micro-optimisation with no real
> justification. I'd prefer to see hexdigest used, as (a) it means md5
> is not a special case, and (b) there's not a proliferation of 1-line
> functions in use code doing that b64encode/strip dance.
> With hexdigest, the syntax is just [algorithm=]hexdigest, where
> algorithm defaults to md5. Much simpler to describe and work with.

Why don't we get just get rid of the backwards-compatible (with a
previous version of PEP 376) "hexdigest defaults to md5" syntax, and
require name=base64 digest. Is there any code that parses the PEP 376

base64 is not hard. I was a little surprised that the optional-padding
versions were not already in the standard library.

def urlsafe_b64encode(data):
    return base64.urlsafe_b64encode(data).rstrip(binary('='))

def urlsafe_b64decode(data):
    pad = b'=' * (4 - (len(data) & 3))
    return base64.urlsafe_b64decode(data + pad)