GeezerVison

Copy link

Copy Markdown

Contributor

srittau reviewed Jun 19, 2020

View reviewed changes

This is a follow-up on python#4232. memoryview, hashlib, and hmac are updated
to use ReadableBuffer type instead of their own home-spun unions of
bytes, bytearray and whatever else each use case used. mmap is being
handled in python#4244, and I'll leave BinaryIO for another day (or possibly
another person) because it's going to require some messy code
duplication because the relevant methods are defined in IO[AnyStr].

There's one corner case I'm not quite sure how best to handle: the
documentation for hmac.digest claim that the parmaeters have the same
meanings as in hmac.new, but in CPython the latter has an explicit check
that `key` is bytes or bytearray while the former works with a
memory-view. For now I've matched the documentation.

Also, the documentation for HMAC.update says that `msg` can be any type
supported by hashlib from Python 3.4; but I can't see anything in the
Python 2.7 implementation that would prevent it also taking bytes-like
objects, so I've not tried to treat Python 2 any different to Python 3.

JelleZijlstra approved these changes Jun 21, 2020

View reviewed changes

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

bmerry deleted the mmap-readable-buffer branch June 22, 2020 06:56

This is a follow-up on #4232. memoryview, hashlib, and hmac are updated
to use ReadableBuffer type instead of their own home-spun unions of
bytes, bytearray and whatever else each use case used. mmap is being
handled in #4244, and I'll leave BinaryIO for another day (or possibly
another person) because it's going to require some messy code
duplication because the relevant methods are defined in IO[AnyStr].

There's one corner case I'm not quite sure how best to handle: the
documentation for hmac.digest claim that the parmaeters have the same
meanings as in hmac.new, but in CPython the latter has an explicit check
that `key` is bytes or bytearray while the former works with a
memory-view. For now I've matched the documentation.

Also, the documentation for HMAC.update says that `msg` can be any type
supported by hashlib from Python 3.4; but I can't see anything in the
Python 2.7 implementation that would prevent it also taking bytes-like
objects, so I've not tried to treat Python 2 any different to Python 3.

* Update mmap stubs for newer Python versions

Based on the Python stdlib documentation:
- Since Python 3.5, mmap.{find,rfind,write} all accept any bytes-like.
  I've used the _typeshed.ReadableBuffer alias defined in python#4232.
- Since Python 3.6, mmap.write returns the number of bytes written.
- Since Python 3.3, mmap.read allows None as the parameter; while in
  Python 2 the argument cannot be omitted.

* Further clean up mmap.pyi

Use the fact that Python 3.0-3.4 are no longer supported to clean up the
version-dependent logic. Functions that always have different signatures
in Python 2/3 are moved from the base _mmap[bytes] to the mmap subclass.

This is a follow-up on python#4232. memoryview, hashlib, and hmac are updated
to use ReadableBuffer type instead of their own home-spun unions of
bytes, bytearray and whatever else each use case used. mmap is being
handled in python#4244, and I'll leave BinaryIO for another day (or possibly
another person) because it's going to require some messy code
duplication because the relevant methods are defined in IO[AnyStr].

There's one corner case I'm not quite sure how best to handle: the
documentation for hmac.digest claim that the parmaeters have the same
meanings as in hmac.new, but in CPython the latter has an explicit check
that `key` is bytes or bytearray while the former works with a
memory-view. For now I've matched the documentation.

Also, the documentation for HMAC.update says that `msg` can be any type
supported by hashlib from Python 3.4; but I can't see anything in the
Python 2.7 implementation that would prevent it also taking bytes-like
objects, so I've not tried to treat Python 2 any different to Python 3.