In python 3.6.5: hashlib blake2b/blake2s constructors do not recognize 'data' keyword. Try the following:

from hashlib import blake2b
print (blake2b(b"foobar").hexdigest()) # works
print (blake2b(data=b"foobar").hexdigest()) # TypeError: 'data' is an invalid keyword argument for this function

None of the hashlib functions are taking keyword arguments for data:

>>> hashlib.sha256(data=b'foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: openssl_sha256() takes no keyword arguments
>>> hashlib.blake2b(data=b'foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'data' is an invalid keyword argument for this function

None of the hashlib functions are taking keyword arguments for data: ...

So it's just a documentation issue, no?

https://docs.python.org/dev/library/hashlib.html#creating-hash-objects

Juuso Lehtivarjo: do you want to write a pull request to fix the documentation?

This was introduced as part of https://hg.python.org/cpython/rev/4969f6d343b1 . In addition to the signature there is also a line at https://docs.python.org/dev/library/hashlib.html#simple-hashing which could be removed

As a shortcut, you can pass the first chunk of data to update directly to the constructor as the first argument (or as data keyword argument)

Thanks

hashlib.blake2b() and some other constructors accept the first chunk of data as the "string" keyword argument.

>>> hashlib.blake2b(string=b'')
<_blake2.blake2b object at 0x7f2847a9c430>
>>> hashlib.blake2s(string=b'')
<_blake2.blake2s object at 0x7f28468f6290>
>>> hashlib.sha3_224(string=b'')
<_sha3.sha3_224 object at 0x7f28468f6608>
>>> hashlib.sha3_256(string=b'')
<_sha3.sha3_256 object at 0x7f28468f6290>
>>> hashlib.sha3_384(string=b'')
<_sha3.sha3_384 object at 0x7f28468f6608>
>>> hashlib.sha3_512(string=b'')
<_sha3.sha3_512 object at 0x7f28468f6290>
>>> hashlib.shake_128(string=b'')
<_sha3.shake_128 object at 0x7f28468f6608>
>>> hashlib.shake_256(string=b'')
<_sha3.shake_256 object at 0x7f28468f6290>

Please treat the first argument as positional-only argument. I don't want to standardize on 'string'.

I take this issue because there are many other issues with handling arguments in the hashlib module.

New changeset f1d36d8 by Serhiy Storchaka in branch 'master':
bpo-33729: Fix issues with arguments parsing in hashlib. (GH-8346)
f1d36d8

New changeset 47957da by Serhiy Storchaka in branch '3.7':
[3.7] bpo-33729: Fix issues with arguments parsing in hashlib. (GH-8346) (GH-8581)
47957da

Your PR changed way to many aspects of the code in one commit. I also don't like the fact, that you pushed such a big change without waiting for my feedback. For the past two weeks I have been travelling to conferences and had no time to review your PR. There was no need to rush it.

The backport to 3.6 and 3.7 are breaking backwards compatibility and compatibility with PEP-247.

Sorry. Do you prefer to revert the whole changes or just some parts?

I have no opinion on the change in the master branch, but I agree with Christian that the 3.7 change should be reverted since it breaks the backward compatibility.

Serhiy modified int() in Python 3.7 to convert its first parameter to positional only parameter. IMHO it's ok to do such change. Moreover, the change has been documented in What's New in Python 3.7:
https://docs.python.org/dev/whatsnew/3.7.html#api-and-feature-removals

If you decide to keep the change in the master branch, it should be documented in What's New in Python 3.8, no?

In case of int() the name of it's first argument was documented, in both the module documentation, and in interactive help. But the documented name of the first blake2b() argument was "data", and it never worked. Since help() was not worked for blake2b, the user had weak chance to know that the actual name is "string". Thus there is much less chance of breaking the user code by making this parameter a positional-only than in case of int().

But I think Christian has other concerns.

What's the status of this issue for 3.7 and for 3.6? Is everyone OK with what is currently in 3.7, i.e. no revert needed or has it already been reverted elsewhere? Also, there is the open PR for 3.6.

Ned, I'm currently travelling until next weekend. The PR is rather large and I don't have any means or time to review it properly. Perhaps Gregory or Dmitry Chestnykh (original author of pyblake2) are able to assist.

OK. This is now blocking the release of 3.7.1rc2 and 3.6.7rc2. See also bpo-34922.

The question remains if Christian's and Victor's concern with 3.7 compatibility have been satisfied by Serihy's response in msg322798. While there is plenty of time to resolve concerns about what was merged into master by PR 8346, we shouldn't release the PR 8581 changes in 3.7.1 if there are still valid compatibility concerns. Since PR 9657 for 3.6 hasn't been reviewed or merged, the only pressing issue for 3.6.7 is ensuring the segfault documented in bpo-34922 is blocked, correct? And PR 8581 prevents the segfault for 3.7 so we would only need a similar fix for it if the PR were reverted, correct?

I have reviewed PR 8346 yet one time. No documented working behavior was changed. Some documentation was updated to match the code, some code was updated to match the documentation, and other minor errors were fixed. I don't think this change breaks compatibility.

Other variant of the crash in bpo-34922 still is reproducible in 3.7.

New changeset f543e18 by Serhiy Storchaka in branch '3.6':
[3.6] bpo-33729: Fix issues with arguments parsing in hashlib. (GH-8346) (GH-8581) (GH-9657)
f543e18

Serhiy's fixes (thanks!) are now released in 3.7.0rc2 and 3.6.7rc2 so I'm removing the "release blocker" status. If there is nothing more to be done for this issue, can we close it?