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
{{ message }}
Required/NotRequired don't work with __future__.annotations #55
Required/NotRequired aren't properly detected when from __future__ import annotations is used, leading to incorrect __required_keys__/__optional_keys__ sets.
Reproduced with 4.3.0.
from __future__ importannotations# comment this line out and things work correctlyfromtyping_extensionsimportNotRequired, TypedDictclassTest(TypedDict):
a: intb: NotRequired[int]
assertTest.__required_keys__== {"a"}
assertTest.__optional_keys__== {"b"}
I can reproduce using typing.TypedDict and typing.NotRequired on the CPython main branch (3.12), so I assume it reproduces on 3.11 using the stdlib typing module as well.
So is this fixed by #60 or not? It seems to be an issue with the upstream cpython typing module as well -- did someone already file an issue there? Please link it here.
#60 would fix this in simple cases, but I think it will cause more problems than it solves. I'm inclined to wontfix this. Maybe we can revisit once there's a resolution on the PEP 563/649 saga.
It's fine to not want to solve this for now. In fact one could argue that, since the point of from __future__ import annotations is not to incur runtime costs, you get what you ask for. (Not sure if that's totally fair, but it's a possible POV.)
I'm closing this here in favor of python/cpython#97727. It seems that the consensus is that it's too complex to fix and will go away by itself at some distant point in the future when the future import isn't required anymore.
I now had this problem too. Inspired by python/cpython#97727 (comment) I made these 4 utility functions to get the correct __required_keys__ / __optional_keys__, extend for __readonly_keys__ in a similar way.
Activity
JelleZijlstra commentedon Jul 11, 2022
What Python version are you running? Does this reproduce with
typingtoo on Python 3.11?jcrist commentedon Jul 11, 2022
I don't have (easy) access to a 3.11 build, but it reproduces with 4.3.0 on both 3.10 and 3.9.
AlexWaygood commentedon Jul 12, 2022
I can reproduce using
typing.TypedDictandtyping.NotRequiredon the CPythonmainbranch (3.12), so I assume it reproduces on 3.11 using the stdlibtypingmodule as well.yixun-alpha commentedon Sep 2, 2022
just ran into this issue with 4.3.0 and python 3.7.6 - any fix in the works? thanks!
gvanrossum commentedon Sep 2, 2022
So is this fixed by #60 or not? It seems to be an issue with the upstream cpython typing module as well -- did someone already file an issue there? Please link it here.
JelleZijlstra commentedon Sep 2, 2022
#60 would fix this in simple cases, but I think it will cause more problems than it solves. I'm inclined to wontfix this. Maybe we can revisit once there's a resolution on the PEP 563/649 saga.
gvanrossum commentedon Sep 2, 2022
It's fine to not want to solve this for now. In fact one could argue that, since the point of
from __future__ import annotationsis not to incur runtime costs, you get what you ask for. (Not sure if that's totally fair, but it's a possible POV.)srittau commentedon Sep 2, 2024
I'm closing this here in favor of python/cpython#97727. It seems that the consensus is that it's too complex to fix and will go away by itself at some distant point in the future when the future import isn't required anymore.
Daraan commentedon Mar 28, 2025
I now had this problem too. Inspired by python/cpython#97727 (comment) I made these 4 utility functions to get the correct
__required_keys__/__optional_keys__, extend for__readonly_keys__in a similar way.