Repository navigation
Positional arguments to TypedDict constructor #2161
Description
The spec says "The constructor takes only keyword arguments, corresponding to the items of the TypedDict." This derives from wording in PEP 589 "It can be used as a callable object with keyword arguments corresponding to the TypedDict items. Non-keyword arguments are not allowed."
But at runtime, the TypedDict constructor also takes positional arguments. This works:
from typing import TypedDict
class TD1(TypedDict):
a: int
class TD2(TD1):
b: str
def f(x: TD2) -> TD1:
return TD1(x)Pyright allows this program; mypy does not and reports Expected keyword arguments, {...}, or dict(...) in TypedDict constructor.
The spec should say whether or not this should be allowed. (My opinion: it should be allowed, since it works at runtime and doesn't appear to break any type safety rule.)
At runtime, even more is allowed; the TypedDict constructor actually allows whatever dict() allows. So you could do TD1([("a", 1)]), or TD1(TD2, a=3). Pyright allows some but not all of that. I'm inclined to prohibit anything other than calls with keyword arguments and calls with a single positional argument of TypedDict type; anything else is rarely useful and prone to unsound behavior.
Activity
BHUVANSH855 commentedon Apr 7, 2026
Hi @JelleZijlstra,
I’d like to work on this issue. I reviewed the current TypedDict specification and noticed that the constructor is still defined as accepting only keyword arguments, while positional arguments are not addressed in the spec.
I plan to align the specification with the intended behavior discussed here and add corresponding conformance tests to clearly define how positional arguments should be handled, including any valid and invalid cases.
Please let me know if this approach looks good or if there are specific constraints I should keep in mind before proceeding.
JelleZijlstra commentedon Apr 7, 2026
The hard work here is getting alignment on what exactly should be specified. I gave my opinions above but we shouldn't necessarily implement all of my opinions.
It's useful to explore more what type checkers currently accept (useful tools may be https://github.com/astral-sh/multiplay and https://github.com/JelleZijlstra/typechecker-matrix), and to post on discuss.python.org to get community feedback.
I haven't personally invested more time in this issue since it seems fairly low impact. But you are welcome to propose a spec change here!
BHUVANSH855 commentedon Apr 7, 2026
Hi @JelleZijlstra,
I’ve opened a PR proposing a spec clarification and corresponding conformance tests for this issue.
Looking forward to your feedback!