[ty] Add more ParamSpec validation for P.args and P.kwargs#23640
Merged
AlexWaygood merged 5 commits intomainfrom Mar 1, 2026
Merged
[ty] Add more ParamSpec validation for P.args and P.kwargs#23640AlexWaygood merged 5 commits intomainfrom
P.args and P.kwargs#23640AlexWaygood merged 5 commits intomainfrom
Conversation
P.args and P.kwargs
15770b3 to
e35f18f
Compare
Typing conformance results improved 🎉The percentage of diagnostics emitted that were expected errors increased from 85.66% to 85.77%. The percentage of expected errors that received a diagnostic increased from 76.56% to 77.22%. Summary
True positives addedDetails
|
|
Memory usage reportSummary
Significant changesClick to expand detailed breakdownprefect
sphinx
trio
flake8
|
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
invalid-paramspec |
17 | 0 | 0 |
invalid-argument-type |
1 | 0 | 0 |
| Total | 18 | 0 | 0 |
Member
Author
|
The new ecosystem hits look like true positives. |
charliermarsh
approved these changes
Mar 1, 2026
Member
charliermarsh
left a comment
There was a problem hiding this comment.
Did you consider moving this logic into free functions in a separate paramspec.rs file or similar?
Member
Author
Good idea, I'll do that |
Add several new `invalid-paramspec` diagnostics for invalid usage of ParamSpec components: - P.args/P.kwargs on regular (non-variadic) parameters - P.args/P.kwargs as variable or instance attribute annotations - *args: P.args without matching **kwargs: P.kwargs (and vice versa) - *args: P.args with **kwargs annotated with a non-matching type - Keyword-only parameters between *args: P.args and **kwargs: P.kwargs - Mismatched ParamSpecs between *args and **kwargs These checks address several `# E` assertions from the typing conformance test `generics_paramspec_components.py`. https://claude.ai/code/session_01BNCtgwYBcEEFDEfuzWPLpQ
- "When using ... no other parameters can appear between ..." → "No parameters may appear between `*args: P.args` and `**kwargs: P.kwargs`" - "`P.args` is not valid in this position; it can only be used to ..." → "`P.args` is only valid for annotating `*args`" - "`**kwargs` must be annotated with ... (to match ...)" → "`*args: P.args` must be accompanied by `**kwargs: P.kwargs`" https://claude.ai/code/session_01BNCtgwYBcEEFDEfuzWPLpQ
…pec errors Distinguishes "`P.args` is only valid for annotating `*args`" (inside a parameter list) from "`P.args` is only valid for annotating `*args` function parameters" (variable/attribute annotations). https://claude.ai/code/session_01BNCtgwYBcEEFDEfuzWPLpQ
Instead of hardcoding `*args` and `**kwargs` in error messages like "`*args: P.args` must be accompanied by `**kwargs: P.kwargs`", use the actual variadic-positional and keyword-variadic parameter names from the function signature. For example, `def f(*my_args: P.args)` now produces "`*my_args: P.args` must be accompanied by `**kwargs: P.kwargs`". https://claude.ai/code/session_01BNCtgwYBcEEFDEfuzWPLpQ
810c1a9 to
3d28da8
Compare
carljm
added a commit
that referenced
this pull request
Mar 2, 2026
* main: [ty] Move binary expression logic out of `builder.rs` (#23649) [ty] Limit recursion depth when displaying self-referential function types (#23647) [ty] Move comparison logic out of `builder.rs` (#23646) Avoid inserting redundant `None` elements in UP045 (#23459) [ty] Add more ParamSpec validation for `P.args` and `P.kwargs` (#23640) [ty] Sync vendored typeshed stubs (#23642) [ty] Fix inference of `t.__mro__` if `t` is an instance of `type[Any]` (#23632) [ty] Detect inconsistent generic base class specializations (#23615) [ty] Validate type variable defaults don't reference later type parameters or type parameters out of scope (#23623) [ty] Ban nested `Required`/`NotRequired`, and ban them both outside of `TypedDict` fields (#23627) [ty] Reject generic metaclasses parameterized by type variables (#23628) Update default Python version examples (#23605) fix binops with NewType of float and Unknown (#23620) [ty] Reject functions with PEP-695 type parameters that shadow type parameters from enclosing scopes (#23619) [ty] Reject ellipsis literals in odd places in type/annotation expressions (#23611) [ty] hash-cons `UseDefMap` fields (#23283)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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
Implement comprehensive validation for
ParamSpeccomponents (P.argsandP.kwargs) in function signatures and variable annotations. This change enforces several rules from the typing specification:P.argsandP.kwargscan only be used as annotations for*argsand**kwargsparameters respectively*args: P.argsis present,**kwargs: P.kwargsmust also be present (and refer to the sameParamSpec)*args: P.argsand**kwargs: P.kwargsP.argsandP.kwargscannot be used in variable annotations or other contextsTest Plan
mdtests