Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect redundant unions with buffer/bytes types? #414

Closed
Akuli opened this issue Jul 22, 2023 · 3 comments
Closed

Detect redundant unions with buffer/bytes types? #414

Akuli opened this issue Jul 22, 2023 · 3 comments

Comments

@Akuli
Copy link
Collaborator

Akuli commented Jul 22, 2023

Currently this annotation doesn't cause a lint error: (taken from python/typeshed#10432 )

from _typeshed import ReadOnlyBuffer

def farm_msg(__farm_name: str, __message: str | bytes | ReadOnlyBuffer) -> None: ...

If I understand the buffer situation correctly, bytes | ReadOnlyBuffer is equivalent to ReadOnlyBuffer, because typeshed claims that bytes implements __buffer__ on all Python versions.

It feels like a good idea to detect unions where bytes types are used like this, similar to Literal[1] | int and other checks we already have. But it feels like a bad idea to make flake8-pyi aware of _typeshed.ReadOnlyBuffer etc and their subtyping rules. I'm not sure.

@AlexWaygood
Copy link
Collaborator

It feels like a good idea to detect unions where bytes types are used like this, similar to Literal[1] | int and other checks we already have. But it feels like a bad idea to make flake8-pyi aware of _typeshed.ReadOnlyBuffer etc and their subtyping rules. I'm not sure.

A general-purpose way of detecting redundant unions could only ever be implemented by a type checker, since they're much better equipped to resolve imports across modules than we'll ever be. We have a much simpler design that only analyses a module at a time, and I'd like to keep it that way (I'm not sure flake8's plugin system even would allow us to analyse multiple modules at a time). So we'll need to weigh up whether it's worth special-casing these specific types from _typeshed or not.

@Avasam
Copy link
Contributor

Avasam commented Oct 16, 2023

Relevant pyright discussion: microsoft/pyright#3949

@AlexWaygood
Copy link
Collaborator

So we'll need to weigh up whether it's worth special-casing these specific types from _typeshed or not.

My feeling is that this probably doesn't come up enough for it to be worth adding this special-casing — WDYT?

@AlexWaygood AlexWaygood closed this as not planned Won't fix, can't repro, duplicate, stale Nov 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants