[red-knot] Move name field on parameter kind#16830
Merged
dhruvmanila merged 1 commit intomainfrom Mar 18, 2025
Merged
Conversation
Previously, the `name` field was on `Parameter` which required it to be always optional regardless of the parameter kind because a `typing.Callable` signature does not have name for the parameters. This is the case for positional-only parameters. This wasn't enforced at the type level which meant that downstream usages would have to unwrap on `name` even though it's guaranteed to be present. This commit moves the `name` field from `Parameter` to the `ParameterKind` variants and makes it optional only for `ParameterKind::PositionalOnly` variant while required for all other variants. One change that's now required is that a `Callable` form using a gradual form for parameter types (`...`) would have a default `args` and `kwargs` name used for variadic and keyword-variadic parameter kind respectively. This is also the case for invalid `Callable` type forms. I think this is fine as names are not relevant in this context but happy to make it optional even in variadic variants.
dhruvmanila
requested review from
AlexWaygood,
carljm,
dcreager and
sharkdp
as code owners
Contributor
|
dcreager
approved these changes
Mar 18, 2025
dcreager
added a commit
that referenced
this pull request
Mar 18, 2025
* main: [playground] Avoid concurrent deployments (#16834) [red-knot] Infer `lambda` return type as `Unknown` (#16695) [red-knot] Move `name` field on parameter kind (#16830) [red-knot] Emit errors for more AST nodes that are invalid (or only valid in specific contexts) in type expressions (#16822) [playground] Use cursor for clickable elements (#16833) [red-knot] Deploy playground on main (#16832) Red Knot Playground (#12681) [syntax-errors] PEP 701 f-strings before Python 3.12 (#16543)
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
3 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
Previously, the
namefield was onParameterwhich required it to be always optional regardless of the parameter kind because atyping.Callablesignature does not have name for the parameters. This is the case for positional-only parameters. This wasn't enforced at the type level which meant that downstream usages would have to unwrap onnameeven though it's guaranteed to be present.This commit moves the
namefield fromParameterto theParameterKindvariants and makes it optional only forParameterKind::PositionalOnlyvariant while required for all other variants.One change that's now required is that a
Callableform using a gradual form for parameter types (...) would have a defaultargsandkwargsname used for variadic and keyword-variadic parameter kind respectively. This is also the case for invalidCallabletype forms. I think this is fine as names are not relevant in this context but happy to make it optional even in variadic variants.Test Plan
No new tests; make sure existing tests are passing.