-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[ty] allow any string Literal type expression as a key when constructing a TypedDict
#20792
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…cting a `TypedDict`
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
AlexWaygood
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great -- thank you!
FWIW I think the spec only states this for I think we can also update our bidirectional inference code, which makes the same assumption. |
…ucting a `TypedDict` (#20806) ## Summary Based on @ibraheemdev's comment on #20792: > I think we can also update our bidirectional inference code, [which makes the same assumption](https://github.com/astral-sh/ruff/blob/main/crates/ty_python_semantic/src/types/infer/builder.rs?rgh-link-date=2025-10-09T21%3A30%3A31Z#L5860). This PR also adds more test cases for how `TypedDict` annotations affect generic call inference. ## Test Plan New tests in `typed_dict.md`
Summary
This PR allows any string
Literaltype expression to be used as a key when constructing aTypedDict.The pattern of reusing constant key strings when constructing a
TypedDictseems to be common in several libraries (e.g., home-assistant/core).Currently, we only accept string literal keys when constructing a
TypedDict, but any expression that can be inferred to be of type stringLiteralis also acceptable. In fact, the spec explicitly states thatLiteraltype expressions andFinalnames should be allowed.Test Plan
New tests in
typed_dict.md