[ty] Add disjointness for protocol method members#25315
Conversation
Typing conformance resultsNo changes detected ✅Current numbersThe percentage of diagnostics emitted that were expected errors held steady at 91.94%. The percentage of expected errors that received a diagnostic held steady at 87.09%. The number of fully passing files held steady at 92/134. |
Memory usage reportSummary
Significant changesClick to expand detailed breakdownprefect
trio
sphinx
flake8
|
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
invalid-argument-type |
0 | 2 | 0 |
| Total | 0 | 2 | 0 |
Raw diff:
scikit-learn (https://github.com/scikit-learn/scikit-learn)
- sklearn/externals/array_api_extra/_lib/_funcs.py:132:44 error[invalid-argument-type] Argument to function `array_namespace` is incorrect: Expected `Array | int | float | complex | None`, found `object`
scipy (https://github.com/scipy/scipy)
- subprojects/array_api_extra/src/array_api_extra/_lib/_funcs.py:148:44 error[invalid-argument-type] Argument to function `array_namespace` is incorrect: Expected `Array | int | float | complex | None`, found `object`4d33c60 to
f3df1ce
Compare
86d8a90 to
617e16c
Compare
94a4ba2 to
43fb9d3
Compare
d9f1196 to
3921ec4
Compare
58247e2 to
7bd614b
Compare
9a39019 to
248cd6c
Compare
Merging this PR will not alter performance
Comparing Footnotes
|
There was a problem hiding this comment.
Nice! Have you checked what the reason is for the ecosystem hits going away?
When I suggested this, I was thinking we'd do this in Callable <-> Callable disjointness rather than Protocol <-> <other type> disjointness. In general, we want disjointness for Protocols with method members to be consistent with disjointness for Callables -- protocols with method members generally just delegate to type relations on Callables, broadly speaking. Making this patch more general would broaden the unsoundness, though, so maybe it's better to go for this limited patch now and experiment with generalising it as a followup
| static_assert(is_subtype_of(NeverLengthSubclass, LengthThree)) | ||
| static_assert(is_subtype_of(NeverLengthSubclass, HasLengthTwo)) | ||
|
|
||
| # Intentionally unsound: `NeverLengthSubclass` inhabits both operands. |
There was a problem hiding this comment.
| # Intentionally unsound: `NeverLengthSubclass` inhabits both operands. | |
| # Intentionally unsound: `NeverLengthSubclass` inhabits both operands, | |
| # but pragmatically, nobody is ever likely to write such a class |
248cd6c to
a30f5b9
Compare
|
It looks like it's because we now prove that |
* main: [`pydocstyle`] Improve discoverability of rules enabled for each convention (#24973) [ty] Deduplicate retained use-def place states (#25450) [ty] reduce features of low-level crates depended on by `ty_python_semantic` (#25524) [ty] Fix narrowing enum literal unions by member identity (#25520) [ty] Test tagged union narrowing for named tuples (#25519) [ty] Disallow file-system access in `ty_python_core` (#25518) [ty] Nominal Tagged Union Narrowing (#24916) Commit `scripts/uv.lock` (#25517) Fix potential index out of range in `LineIndex` computation (#25492) [ty] Sync vendored typeshed stubs (#25514) [ty] Add disjointness for protocol method members (#25315) [ty] Use compact sets for more immutable fields (#25476) [ty] Derive `Default` for `FunctionDecoratorInference` (#25482) [ty] Ignore rejected assignments for synthesized bindings (#25340) [ty] Handle cycles in function decorator inference (#25475) docs: fix typo `bin/active` → `bin/activate` in tutorial (#25473) [ty] Narrow bound method overloads by receiver (#24707)
|
Filed astral-sh/ty#3618 and astral-sh/ty#3619 with some follow-up thoughts on the unsoundness here. |
Summary
This PR implements disjointness checking for protocols with method members by comparing non-
Neverreturn types, e.g., we now understand that a fixed-length tuple whose synthesized__len__returnsLiteral[3]is disjoint from a protocol requiring__len__to returnLiteral[2]:This is a prerequisite for using synthesized exact-length protocols to narrow unions of fixed-length tuples and sequence patterns (see: #22134 (comment)).
Per that comment, this isn't fully sound: a subclass can override an otherwise incompatible method with a
Never-returning implementation and therefore inhabit both types that we infer to be disjoint.