Your "just in case the software is exposed to the web" should be "exposed to untrusted data." The very old Python hash could be DoS'ed reading a data file. The

Your "just in case the software is exposed to the web" should be "exposed to untrusted data." The very old Python hash could be DoS'ed reading a data file. The original randomized version required some feedback to figure out the hash, so generally required some sort of interaction. I find that hard to believe that's a performance bottleneck. String hashes are all cached, and names like "print" are interned. For a 2x overall gain I would expect to see the hash function pop up easily in my profiling, but I haven't seen it in my own profiling which was looking for simple things like that. When siphash was evaluated, quoting https://peps.python.org/pep-0456/#performance https://peps.python.org/pep-0456/#performance , "In general the PEP 456 code with SipHash24 is about as fast as the old code with FNV" and "The summarized total runtime of the benchmark is within 1% of the runtime of an unmodified Python 3.4 binary". Since then they switched from siphash24 to the faster siphash13. https://github.com/python/cpython/pull/28752 https://github.com/python/cpython/pull/28752