GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||
GeezerVison is showing github.com — Introduce ReadableBuffer and WriteableBuffer Union aliases by bmerry · Pull Request #4232 · python/typeshed Conversation
Contributor
Since typing doesn't yet have a way to express buffer protocol objects To allow for some uniformity until the fundamental issue is resolved, This unfortunately does have the potential to break code that inherits I'm not 100% happy with the names: bytes-like is slightly stricter than
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactionsSince typing doesn't yet have a way to express buffer protocol objects (python/typing#593), various interfaces have ended up with a mish-mash of options: some list just bytes (or just bytearray, when writable), some include mmap, some include memoryview, I think none of them include array.array even though it's explicitly mentioned as bytes-like, etc. I ran into problems because RawIOBase.readinto didn't allow for memoryview. To allow for some uniformity until the fundamental issue is resolved, I've introduced _typeshed.ReadableBuffer and _typeshed.WriteableBuffer, and applied them in stdlib/3/io.pyi as an example. If these get rolled out in more places, it will mean that we have only one place where they have to get tweaked in future, or swapped out for a public protocol. This unfortunately does have the potential to break code that inherits from RawIOBase/BufferedIOBase and overrides these methods, because the base method is now more general and so the override now needs to accept these types as well (which is why I've also updated gzip and lzma). However, it should be a reasonably easy fix, and will make the downstream annotations more correct. I'm not 100% happy with the names: bytes-like is slightly stricter than just buffer protocol (it must be able to export a C-contiguous buffer), but in practice I'd be surprised if there are types for which there is a difference at static analysis time (e.g. not every memoryview instance is bytes-like, but that's a property of instances, not types).
Contributor
Author
All reactions
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page.
Member
All reactions
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page.
srittau
approved these changes
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks! This looks reasonable. If it turns out, it breaks too much, we might need to temporarily change the types, but collecting the types accepting buffers in
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactions
bmerry
added a commit
to bmerry/typeshed
that referenced
this pull request
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.
bmerry
added a commit
to bmerry/typeshed
that referenced
this pull request
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.
bmerry
added a commit
to bmerry/typeshed
that referenced
this pull request
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
pushed a commit
that referenced
this pull request
* 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 #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.
JelleZijlstra
pushed a commit
that referenced
this pull request
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.
vishalkuo
pushed a commit
to vishalkuo/typeshed
that referenced
this pull request
Since typing doesn't yet have a way to express buffer protocol objects (python/typing#593), various interfaces have ended up with a mish-mash of options: some list just bytes (or just bytearray, when writable), some include mmap, some include memoryview, I think none of them include array.array even though it's explicitly mentioned as bytes-like, etc. I ran into problems because RawIOBase.readinto didn't allow for memoryview. To allow for some uniformity until the fundamental issue is resolved, I've introduced _typeshed.ReadableBuffer and _typeshed.WriteableBuffer, and applied them in stdlib/3/io.pyi as an example. If these get rolled out in more places, it will mean that we have only one place where they have to get tweaked in future, or swapped out for a public protocol. This unfortunately does have the potential to break code that inherits from RawIOBase/BufferedIOBase and overrides these methods, because the base method is now more general and so the override now needs to accept these types as well (which is why I've also updated gzip and lzma). However, it should be a reasonably easy fix, and will make the downstream annotations more correct.
vishalkuo
pushed a commit
to vishalkuo/typeshed
that referenced
this pull request
* 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.
vishalkuo
pushed a commit
to vishalkuo/typeshed
that referenced
this pull request
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ReviewersUh oh!
There was an error while loading. Please reload this page. AssigneesNo one assignedLabels
None yet
ProjectsMilestoneNo milestoneDevelopmentSuccessfully merging this pull request may close these issues. Uh oh!
There was an error while loading. Please reload this page. Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later. | ||
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |