search

python / typeshed

Collection of library stubs for Python, with static types
Other
4.29k stars 1.72k forks source link

Track review of `bytes` types #9006

Open JelleZijlstra opened 1 year ago

JelleZijlstra commented 1 year ago

I'll use this issue to track reviewing all usage of bytes types to see if they should be changed following #9001 and PEP 688. The below list is from git grep -c '\bbytes\b'.

My plan is to do look at each file one by one, reviewing bytes occurrences. I'll generally assume occurrences in return types or IO[bytes] are correct, but check occurrences in argument types to see if they should be ReadableBuffer, bytes, or similar.

hauntsaninja commented 1 year ago

One quick note: I believe we're missing a type that corresponds to Buffer & Sequence[int]. If such a type is ever needed and PEP 688 is accepted and we alias the buffer types in typeshed to types.Buffer, we'll get false negatives. So possibly a thing to look out for and introduce if necessary (_typeshed.ByteSequence?)

AlexWaygood commented 1 year ago

(I wouldn't waste time wading through all the cryptography ones, given how out of date those stubs are — we should just work on getting #5768 done so that we can do #5618.)

JelleZijlstra commented 1 year ago

@hauntsaninja so far I haven't seen much use for that; usually people either want some subset or Sequence, or the buffer protocol, but not both.

@AlexWaygood thanks, that saves a lot of files.

I'm also going to skip all of the deleted and deprecated modules (e.g. from PEP 594) since they're unlikely to affect real users.

AlexWaygood commented 1 year ago

I've ticked off stubs/xxhash/xxhash/__init__.pyi for you as well, since those stubs are obsolete and scheduled for removal (#7142)

JelleZijlstra commented 1 year ago

I am going to stop sending PRs for now since I have >10 open PRs. I'd appreciate reviews on the open ones. :)

AlexWaygood commented 1 year ago

I've ticked off the urllib3 ones, since our stubs for urllib3 are obsolete and scheduled for removal.

shininglove commented 1 year ago

Found an issue with stubs/requests/requests/models.pyi, seems its reporting the return type of Response.content to be bytes, but it seems its return type in the sourcecode is bytes | bool | None

Not sure if this is intended or not. Can help with a PR for it

JelleZijlstra commented 1 year ago

Thanks for checking! Please open a PR (or a separate issue if you're not sure).

I don't know if I'll get around to all the third-party stubs. For a lot of these files it doesn't seem like we're gaining that much by adjusting the bytes types.

Akuli commented 1 year ago

Checked the tree_sitter checkbox, no changes were needed since it only accepts bytes.

``` >>> import tree_sitter_languages >>> p = tree_sitter_languages.get_parser('python') >>> p >>> p.parse(memoryview(b'print(1)')) Traceback (most recent call last): File "", line 1, in TypeError: First argument to parse must be bytes >>> p.parse(bytearray(b'print(1)')) Traceback (most recent call last): File "", line 1, in TypeError: First argument to parse must be bytes >>> p.parse(b'print(1)') ```
Avasam commented 11 months ago

Stripe should resolve itself as 6.8.0b3 includes inline-types https://github.com/stripe/stripe-python/blob/v6.8.0b3/CHANGELOG.md#enable-inline-type-annotations-in-the-beta-channel & https://github.com/stripe/stripe-python/pull/1074