PEP 692 (kwargs TypedDict) tracker

[hmc-cs-mdrissi]

Test example I'm using for support,

from typing import TypedDict

from typing_extensions import Unpack


class Foo(TypedDict, total=False):
    a: int
    b: str


def f(**kwargs: Unpack[Foo]) -> None:
    ...


f(a=1, b="2")  # OK
f(a=1, b=2)  # Error: b has type str
f(a=1, b="2", c=3)  # Error: unexpected keyword argument "c"

• mypy
• pyright
• pytype Support PEP 692 – Using TypedDict for more precise **kwargs typing google/pytype#1558
• pyre
• PyCharm (nice to have, but not required): Open ticket.

pytype and pyre both produce 1 error on f(**kwargs: Unpack[Foo]) . Pytype produces typing_extensions.Unpack not supported yet [not-supported-yet] while pyre produces pep_692.py:11:16 Undefined or invalid type [11]: Annotation Unpack is not defined as a type.

Unsure if typeshed usage for this should wait til pyre/pytype fully support pep 692 or if current status of them not checking lines reliant on 692 is enough (similar to Self type status). pytype/pyre still detect errors normally for other parts of the file.

For mypy side we would also need to adjust line with mypy flags to include --enable-incomplete-feature=Unpack (maybe other incomplete features should be considered too).

Motivation for issue was yesterday I hit some lines in tensorflow stub where 692 would be helpful. Minor though and being explicit on arguments works fine (just adds a couple stubtest allowlist lines).

[srittau]

Thanks for opening this! What would be the effect if someone uses a stub with mypy that uses this feature without --enable-incomplete-feature? Will it be treated as Any or will there be an error? In the latter case we can't use the feature, the former case would be acceptable in my opinion.

[JelleZijlstra]

Since --enable-incomplete-feature is meant for experimental features that may not work properly yet, I think we shouldn't write typeshed stubs that rely on it. But on the mypy side, maybe we can move this aspect of Unpack out of "incomplete" status, since it's a lot simpler to implement than full PEP 646 support.

[tmke8]

What would be the effect if someone uses a stub with mypy that uses this feature without --enable-incomplete-feature?

Here is what mypy reports:

from typing import TypedDict
from typing_extensions import Unpack

class Foo(TypedDict, total=False):
    a: int
    b: str

def f(**kwargs: Unpack[Foo]) -> None:  # E: "Unpack" support is experimental, use --enable-incomplete-feature=Unpack to enable  [misc]
    reveal_type(kwargs)  # N: Revealed type is "builtins.dict[builtins.str, Any]"

reveal_type(f)  # N: Revealed type is "def (**kwargs: Any)"

# (no error in any of the following)
f(a=1, b="2")
f(a=1, b=2)
f(a=1, b="2", c=3)

[hmc-cs-mdrissi]

Sounds reasonable to wait for mypy to enable it by default. I can open up a mypy issue later today.

[kkirsche]

I wanted to provide an update based on the current state of the different tools:

• Pytpe appears to be tracking this at Support PEP 692 – Using TypedDict for more precise **kwargs typing google/pytype#1558
• Pyre 0.9.22 does not appear to support Unpack at this time and I do not see an open issue for it.
• The PyCharm issue states it's fixed and is available in 2024.1.3

As a result, it appears 1 of the remaining 3 type checkers have added support and 1 of the 2 that have not implemented it have an open tracking issue.

[JelleZijlstra]

Thanks @kkirsche, I updated the tracker comment

[yangdanny97]

Pyre's latest release (https://github.com/facebook/pyre-check/releases/tag/v0.9.23) supports Unpack for kwargs, tho the description doesn't mention it and the online sandbox hasn't been updated yet.