[ty] Temporary hack to reduce false positives around builtins.open()
#20367
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.
Summary
#20165 added a lot of false positives around calls to
builtins.open(), because our missing support for PEP-613 type aliases means that we don't understand typeshed's overloads forbuiltins.open()at all yet, and therefore always select the first overload. This didn't use to matter very much, but now that we have a much stricter implementation of protocol assignability/subtyping it matters a lot, because most of the stdlib functions dealing with I/O (pickle,marshal,io,json, etc.) are annotated in typeshed as taking in protocols of some kind.In lieu of full PEP-613 support, which is blocked on various things and might not land in time for our next alpha release, this PR adds some temporary special-casing for
builtins.open()to avoid the false positives. We just inferTodofor anything that isn't meant to match typeshed's firstopen()overload. This should be easy to rip out again once we have proper support for PEP-613 type aliases, which hopefully should be pretty soon!Test Plan
Added an mdtest