[issue39298] add BLAKE3 to hashlib
Gregory P. Smith
report at bugs.python.org
Tue Mar 22 21:12:18 EDT 2022
Gregory P. Smith <greg at krypto.org> added the comment:
Because I don't think blake3 or blake2 _(though we've shipped it already so there's a challenge in making changes https://bugs.python.org/issue47095)_ 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.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________
More information about the Python-bugs-list
mailing list