Does any code parse the PEP 376 digests in RECORD?
Why don't we get just get rid of the backwards-compatible (with aOn Fri, Oct 26, 2012 at 4:11 AM, Paul Moore <email@example.com> wrote:
> On 26 October 2012 08:54, Ronald Oussoren <firstname.lastname@example.org> wrote:
>>> It's nice and small. The encoder is just
>> 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.
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.
pad = b'=' * (4 - (len(data) & 3))
return base64.urlsafe_b64decode(data + pad)