hashlib.blake2b and hashlib.blake2s are represented as the abstract class _BlakeHash but should be represented as instances of _BlakeHash

[quantsini]

Bug Repro:

Running mypy 0.521 on the following python 3.6 snippet (inspiration taken from an example used in the official python 3.6.3 documentation.)

import hashlib
hashlib.blake2b(b'data').hexdigest()
hashlib.blake2s(b'data').hexdigest()

yields

test.py:2: error: Cannot instantiate abstract class '_BlakeHash' with abstract attributes 'copy', 'digest', 'hexdigest' and 'update'
test.py:3: error: Cannot instantiate abstract class '_BlakeHash' with abstract attributes 'copy', 'digest', 'hexdigest' and 'update'

This seems inconsistent with the non-blake derived hash functions (e.g. hashlib.md5(b'data').hexdigest()), which has behavior of passing mypy.

Potential Fix

Spelunking through the code, I believe this can be fixed by replacing

typeshed/stdlib/3/hashlib.pyi

Lines 77 to 78 in c68dcf1

	blake2b = _BlakeHash
	blake2s = _BlakeHash

with

    def blake2b(arg: _DataType = ...) -> _BlakeHash: ...
    def blake2s(arg: _DataType = ...) -> _BlakeHash: ...

(plus any necessary tests to change :))

Running mypy on my local copy of hashlib.pyi passes the checker.

Happy to open a PR but wanted thoughts on this first.

[JelleZijlstra]

See also #1609.

[JelleZijlstra]

This was fixed by #1663.