Description

JelleZijlstra

opened on Jan 28, 2026

Issue body actions

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

1. JelleZijlstra

   added

   topic: otherOther topics not coveredOther topics not covered

   topic: typing specFor improving the typing specFor improving the typing spec

   and removed

   topic: otherOther topics not coveredOther topics not covered

   on Jan 28, 2026
2. BHUVANSH855 commented on Apr 7, 2026

   

   BHUVANSH855

   on Apr 7, 2026

   Contributor

   More actions

   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.
3. JelleZijlstra commented on Apr 7, 2026

   

   JelleZijlstra

   on Apr 7, 2026

   MemberAuthor

   More actions

   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!

   Reacted by Brian Schubert
4. BHUVANSH855 commented on Apr 7, 2026

   

   BHUVANSH855

   on Apr 7, 2026

   Contributor

   More actions

   Hi @JelleZijlstra,

   I’ve opened a PR proposing a spec clarification and corresponding conformance tests for this issue.

   Looking forward to your feedback!

Issue actions