additional keyword arguments that are specific to the selected hashing algorithm

This is going to raise the question of which keywords are available for each algorithm and what they do. It would be nice if we had a summary table (like that at the top of the itertools() documentation).

While you are technically correct, I would like to hold off on this change for a bit more. I plan to replace our internal vendored copies of sha3 and blake2 with OpenSSL code. OpenSSL 1.1.1 has some of the new required APIs. OpenSSL 3.0.0-dev is currently adding more but with slightly different semantic. For example OpenSSL does not have blake2b, but blake2b512 for hashing and blake2bmac for keyed hashing with salting and personalization.

I like to get integration with OpenSSL right until hashlib.new() is officially documented.

This is going to raise the question of which keywords are available for each algorithm and what they do. It would be nice if we had a summary table (like that at the top of the itertools() documentation).

Lets not make such a table. People shouldn't use hashlib.new() in most code. It is a conveinence function for the use case where someone needs to choose a hash algorithm at runtime. I don't want to duplicate documentation for the same thing in two places in hashlib.rst.

The one true canonical place for arguments for any given hash function to be defined is in the documentation for the hashlib.$algorithmname() constructor. Or individual documentation specific to each algorithm should we wind up in a situation where a $algorithmname constructor no longer makes sense (as some of the plethora of suffixed blake$mumble variants might do). Not as part of hashlib.new().

@tiran should this PR be closed then, since the semantic might change anyway after you finish integrating OpenSSL?

@tiran should this PR be closed then, since the semantic might change anyway after you finish integrating OpenSSL?

Makes sense, let's close it. Thanks for your contribution. 👍