You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
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.
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:
fromtypingimportTypedDictfromtyping_extensionsimportUnpackclassFoo(TypedDict, total=False):
a: intb: strdeff(**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)
I think we can start using this (and I think we already have). pytype's development seems to be updated only very infrequently and shouldn't hold us back.
Activity
srittau commentedon Feb 13, 2023
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 asAnyor 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 commentedon Feb 13, 2023
Since
--enable-incomplete-featureis 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 ofUnpackout of "incomplete" status, since it's a lot simpler to implement than full PEP 646 support.tmke8 commentedon Feb 13, 2023
Here is what mypy reports:
hmc-cs-mdrissi commentedon Feb 13, 2023
Sounds reasonable to wait for mypy to enable it by default. I can open up a mypy issue later today.
kkirsche commentedon Oct 21, 2024
I wanted to provide an update based on the current state of the different tools:
Unpackat this time and I do not see an open issue for it.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 commentedon Oct 21, 2024
Thanks @kkirsche, I updated the tracker comment
yangdanny97 commentedon Nov 3, 2024
Pyre's latest release (https://github.com/facebook/pyre-check/releases/tag/v0.9.23) supports
Unpackfor kwargs, tho the description doesn't mention it and the online sandbox hasn't been updated yet.srittau commentedon Jul 16, 2025
I think we can start using this (and I think we already have). pytype's development seems to be updated only very infrequently and shouldn't hold us back.