[ty] Use infer_type_expression for validating PEP-613 type aliases#24370
[ty] Use infer_type_expression for validating PEP-613 type aliases#24370AlexWaygood merged 1 commit intomainfrom
infer_type_expression for validating PEP-613 type aliases#24370Conversation
Typing conformance results improved 🎉The percentage of diagnostics emitted that were expected errors increased from 86.79% to 86.81%. The percentage of expected errors that received a diagnostic increased from 81.72% to 81.90%. The number of fully passing files improved from 70/132 to 71/132. SummaryHow are test cases classified?Each test case represents one expected error annotation or a group of annotations sharing a tag. Counts are per test case, not per diagnostic — multiple diagnostics on the same line count as one. Required annotations (
Test file breakdown2 files altered
True positives added (2)2 diagnostics
True positives changed (14)14 diagnostics
|
Memory usage reportSummary
Significant changesClick to expand detailed breakdownprefect
|
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
invalid-await |
0 | 40 | 0 |
invalid-type-form |
2 | 0 | 0 |
unsupported-operator |
2 | 0 | 0 |
invalid-return-type |
0 | 1 | 0 |
| Total | 4 | 41 | 0 |
Changes in flaky projects detected. Raw diff output excludes flaky projects; see the HTML report for details.
Raw diff:
mypy (https://github.com/python/mypy)
+ mypy/typeshed/stdlib/builtins.pyi:1462:72 error[invalid-type-form] `...` is not allowed in this context in a type alias value
+ mypy/typeshed/stdlib/typing.pyi:944:7 error[invalid-type-form] Invalid subscript of object of type `_SpecialForm` in a type alias value
pydantic (https://github.com/pydantic/pydantic)
+ pydantic/_internal/_utils.py:33:35 error[unsupported-operator] Operator `|` is unsupported between objects of type `<class 'Mapping[int, Any]'>` and `<class 'Mapping[str, Any]'>`
+ pydantic/_internal/_utils.py:34:36 error[unsupported-operator] Operator `|` is unsupported between objects of type `<class 'AbstractSet[int]'>` and `<class 'AbstractSet[str]'>`|
I'm pretty sure the mypy hits are just things getting weird because we don't recognise mypy's vendored typeshed as the "real" typeshed, like we do our own vendored typeshed. The pydantic hits are strictly-speaking false positives because they're using |
|
Hmm, it is worth noting that there are regressions of up to 4% on some real-world benchmarks: https://codspeed.io/astral-sh/ruff/branches/alex-carl/pep-613?utm_source=github&utm_medium=check&utm_content=button&page=2. I guess pydantic uses a lot of PEP-613 type aliases? We only do the double-inference for PEP-613 aliases defined in first-party files. |
carljm
left a comment
There was a problem hiding this comment.
We need this validation, and I don't think we can get it (in an accurate way) without some performance cost on TypeAlias-heavy codebases.
* main: Document adding fixes in CONTRIBUTING.md (#24393) Sort formatter diagnostics in snapshots (#24375) [`pyupgrade`] Fix panic caused by handling of octals in `UP012` (#24390) Upgrade to nix v0.31.2 (#24385) Strip form feeds from indent passed to `dedent_to` (#24381) add recent move of the `deferred` submodule to `.git-blame-ignore-revs` (#24379) [ty] Fix extra_items TypedDict tests (#24367) [ty] Use `infer_type_expression` for validating PEP-613 type aliases (#24370) [`flake8-simplify`] Make the fix for `collapsible-if` (`SIM102`) safe in `preview` (#24371) [ty] Validate TypedDict fields when subclassing (#24338) [ty] pass type context to sequence literals in binary operations (#24197) Add release environment to notify-dependents job (#24372) Bump 0.15.9 (#24369) [ty] Move the `deferred` submodule inside `infer/builder` (#24368) [ty] Infer the `extra_items` keyword argument to class-based TypedDicts as an annotation expression (#24362) [ty] Validate type qualifiers in functional TypedDict fields and the `extra_items` keyword to functional TypedDicts (#24360)
Summary
Replace our ad-hoc validation of type qualifiers and AST structure of PEP-613 type alias values with a second pass over such values after inference has completed. The second pass uses
infer_type_expression, which is much better at handling all possible edge cases of illegal type expressions than the ad-hoc handling we had previously.This PR also fixes a bug where
x: Literal[-3.14]was not detected as an illegal type annotation. Ironically, this was something our previous ad-hoc validation for type aliases did handle, but thatinfer_type_expressiondid not!Co-authored-by: Carl Meyer carl@astral.sh
Test Plan
mdtests extended