This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients Zooko.Wilcox-O'Hearn, christian.heimes, corona10, gregory.p.smith, jstasiak, kmaork, larry, mgorny, oconnor663, xtreak
Date 2022-03-23.01:12:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Because I don't think blake3 or blake2 _(though we've shipped it already so there's a challenge in making changes are important enough to be _guaranteed_ present in all builds (our release binaries would include them). Depending on an external library for those to exist makes sense.

I do not want CPython to get into the business of maintaining a complicated build process in-tree for third party architecture specific optimized code for non-core functionality purposes.  That is best handled outside of the project & on CI and binary release hosts.

I'm okay with blake3 in hashlib if we can avoid gaining another /impl/ tree that is a copy of large third party code and our own build system for it.

Q: What benefits does having blake3 builtin vs getting it from PyPI bring?

Q: Should we instead provide a way for third party provided hashes to be registered in `hashlib` similar to `codecs.register()`?

I view the NIST standard hashes as important enough to attempt to guarantee as present (all the SHAs and MD5) as built-in. Others should really demonstrate practical application popularity to gain included battery status rather than just using PyPI.
Date User Action Args
2022-03-23 01:12:18gregory.p.smithsetrecipients: + gregory.p.smith, larry, christian.heimes, mgorny, Zooko.Wilcox-O'Hearn, jstasiak, oconnor663, corona10, xtreak, kmaork
2022-03-23 01:12:18gregory.p.smithsetmessageid: <>
2022-03-23 01:12:18gregory.p.smithlinkissue39298 messages
2022-03-23 01:12:18gregory.p.smithcreate