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 }}
Repository navigation
TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules #85421
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2021-07-17.09:37:32.514>created_at=<Date2020-07-08.23:47:38.289>labels= ['type-bug', '3.8', '3.9', '3.10', '3.11', '3.7', 'library']
title="TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules"updated_at=<Date2021-07-17.09:37:32.513>user='https://github.com/keithblaha'
I came across this issue while using inheritance to express required keys in a TypedDict, as is recommended by the docs.
It's most easily explained by a minimal example I cooked up. Let's say we have a module foo.py:
from __future__ importannotationsfromtypingimportOptionalfromtyping_extensionsimportTypedDictclassFoo(TypedDict):
a: Optional[int]
And another module bar.py:
from __future__ importannotationsfromtypingimportget_type_hintsfromfooimportFooclassBar(Foo, total=False):
b: intprint(get_type_hints(Bar))
Note that both foo.py and bar.py have adopted postponed evaluation of annotations (PEP-563) by using the __future__ import.
If we execute bar.py, we get the error message NameError: name 'Optional' is not defined.
This is due to the combination of:
get_type_hints relies on the MRO to resolve types: https://github.com/python/cpython/blob/3.7/Lib/typing.py#L970
TypedDict does not preserve the original bases, so Foo is not in the MRO for Bar:
typing/typing_extensions/src_py3/typing_extensions.py
Line 1652 in d79edde
Thus, get_type_hints is unable to resolve the types for annotations that are only imported in foo.py.
I ran this example using typing_extensions 3.7.4.2 (released via #709) and Python 3.7.3, but it seems like this would be an issue using the current main branches of both repositories as well.
I'm wondering what the right approach is to tackling this issue. It is of course solvable by defining Bar in foo.py instead, but it isn't ideal or intuitive to always need to inherit from a TypedDict in the same module.
I was thinking that similarly to __required_keys__ and __optional_keys__, the TypedDict could preserve its original bases in a new dunder attribute, and get_type_hints could work off of that instead of MRO when it is dealing with a TypedDict. I would be willing to contribute the PRs to implement this if the design is acceptable, but am open to other ideas as well.
I was thinking that similarly to __required_keys__ and __optional_keys__, the TypedDict could preserve its original bases in a new dunder attribute, and get_type_hints could work off of that instead of MRO when it is dealing with a TypedDict. I would be willing to contribute the PRs to implement this if the design is acceptable
TBH this is not very elegant, but I think you can go ahead with this (at least as a quick fix) since I don't see a better solution yet.
keithblaha commented on Jul 16, 2020
keithblahamannequin
MannequinAuthor
More actions
TBH this is not very elegant, but I think you can go ahead with this (at least as a quick fix) since I don't see a better solution yet.
Agreed, given that the current workaround of implementing them in the same module works I think I will stick with that while this is brainstormed further.
Septatrix commented on May 29, 2021
Septatrixmannequin
Mannequin
More actions
What is/was the initial reason to not preserve the MRO for a TypedDict?
The only thing which came to my mind would be instantiation performance but as annotations are not evaluated by default and on the right-hide side of assignment most people will use dict literals I am not sure if this is still relevant. Otherwise it might even be simpler to just preserve the original bases in TypedDict but please correct me if I overlooked something
What is/was the initial reason to not preserve the MRO for a TypedDict?
Hm, I can't say for sure. I believe it had something to do with TypedDict instances being instances of dict at runtime, but I can't actually reconstruct the reason. Maybe it's written up in PEP-589, but I suspect not (I skimmed and couldn't find it). If you ask on typing-sig maybe David Foster (who contributed the initial idea and implementation) remembers.
Septatrix commented on Jun 7, 2021
Septatrixmannequin
Mannequin
More actions
I believe it had something to do with TypedDict instances being instances of dict at runtime, but I can't actually reconstruct the reason.
Hm that may be true.
My limited low-level Python knowledge leads me to believe that this could also be done using __new__ but I also read that most magic methods get called as type(Foo).__magic__(bar, ...) so that might not be possible.
(However also no methods can be declared on a TypedDict class so that might not be a problem?)
Maybe it's written up in PEP-589, but I suspect not (I skimmed and couldn't find it).
I read it completely and could not find anything
If you ask on typing-sig maybe David Foster (who contributed the initial idea and implementation) remembers.
Note that this issue is now only a problem of you use from __future__ import annotations -- we rolled the default behavior for 3.10 back to what it was in 3.9.
I am out of time to argue about why we chose this behavior, alas.
Kronuz commented on Jul 3, 2021
Kronuzmannequin
Mannequin
More actions
The way I fixed this is I added __forward_module__ to typing.ForwardRef, so that it can resolve the forward reference with the same globals as the ones specified by the module in __forward_module__. TypedDict's metaclass should then pass the dictionary’s module name to the annotations’ forward references via the added module’s keyword argument in typing._type_check(). I can work in a pull request with this solution and discuss any potential problems.
Septatrix commented on Jul 3, 2021
Septatrixmannequin
Mannequin
More actions
The way I fixed this is I added __forward_module__ to typing.ForwardRef, so that it can resolve the forward reference with the same globals as the ones specified by the module in __forward_module__. TypedDict's metaclass should then pass the dictionary’s module name to the annotations’ forward references via the added module’s keyword argument in typing._type_check(). I can work in a pull request with this solution and discuss any potential problems.
While this seems like a good solution I would still like to figure out why TypedDict do not preserve MRO. Because for now I have not found a reason nor did someone on the typing-sig mailinglist have a clue. Should there (no longer) be a reason for this then this problem has a trivial solution (just re-add the MRO and use that).
Kronuz commented on Jul 3, 2021
Kronuzmannequin
Mannequin
More actions
Nils, unfortunately, fixing the MRO here won’t fix the issue because TypedDict.__annotations__ in the class copies the annotations from the parent classes, and when the type evaluation is made, it’s made using the copied annotation found in the bottommost class (which is thus then expected to be a forward reference in the same module as the class that inherited them. This producing the exact same problem of missing type.
The most likely reason for incomplete MRO is that TypeDict extends a class’ __annotations__ with all of it’s parent’s __annotations__, so the final class has the complete set of annotations of all of its parents, so having the full inheritance chain made less sense, after all the final dictionary class has all the annotations.
The way I fixed this is I added __forward_module__ to typing.ForwardRef, so that it can resolve the forward reference with the same globals as the ones specified by the module in __forward_module__. TypedDict's metaclass should then pass the dictionary’s module name to the annotations’ forward references via the added module’s keyword argument in typing._type_check(). I can work in a pull request with this solution and discuss any potential problems.
While this seems like a good solution I would still like to figure out why TypedDict do not preserve MRO. Because for now I have not found a reason nor did someone on the typing-sig mailinglist have a clue. Should there (no longer) be a reason for this then this problem has a trivial solution (just re-add the MRO and use that).
It will work in 3.10 and 3.9 without issues. However, I don't remember if bugfixes for __future__ features require special treatment/are excluded from normal bugfix backports. I vaguely remember us not backporting from __future__ annotations very far back (since they usually broke backwards compatibility).
Activity
keithblaha commentedon Jul 8, 2020
Copied from python/typing#737
I came across this issue while using inheritance to express required keys in a TypedDict, as is recommended by the docs.
It's most easily explained by a minimal example I cooked up. Let's say we have a module foo.py:
And another module bar.py:
Note that both foo.py and bar.py have adopted postponed evaluation of annotations (PEP-563) by using the __future__ import.
If we execute bar.py, we get the error message NameError: name 'Optional' is not defined.
This is due to the combination of:
Thus, get_type_hints is unable to resolve the types for annotations that are only imported in foo.py.
I ran this example using typing_extensions 3.7.4.2 (released via #709) and Python 3.7.3, but it seems like this would be an issue using the current main branches of both repositories as well.
I'm wondering what the right approach is to tackling this issue. It is of course solvable by defining Bar in foo.py instead, but it isn't ideal or intuitive to always need to inherit from a TypedDict in the same module.
I was thinking that similarly to __required_keys__ and __optional_keys__, the TypedDict could preserve its original bases in a new dunder attribute, and get_type_hints could work off of that instead of MRO when it is dealing with a TypedDict. I would be willing to contribute the PRs to implement this if the design is acceptable, but am open to other ideas as well.
ilevkivskyi commentedon Jul 16, 2020
TBH this is not very elegant, but I think you can go ahead with this (at least as a quick fix) since I don't see a better solution yet.
keithblaha commentedon Jul 16, 2020
Agreed, given that the current workaround of implementing them in the same module works I think I will stick with that while this is brainstormed further.
Septatrix commentedon May 29, 2021
What is/was the initial reason to not preserve the MRO for a TypedDict?
The only thing which came to my mind would be instantiation performance but as annotations are not evaluated by default and on the right-hide side of assignment most people will use dict literals I am not sure if this is still relevant. Otherwise it might even be simpler to just preserve the original bases in TypedDict but please correct me if I overlooked something
gvanrossum commentedon May 29, 2021
Hm, I can't say for sure. I believe it had something to do with TypedDict instances being instances of dict at runtime, but I can't actually reconstruct the reason. Maybe it's written up in PEP-589, but I suspect not (I skimmed and couldn't find it). If you ask on typing-sig maybe David Foster (who contributed the initial idea and implementation) remembers.
Septatrix commentedon Jun 7, 2021
Hm that may be true.
My limited low-level Python knowledge leads me to believe that this could also be done using __new__ but I also read that most magic methods get called as type(Foo).__magic__(bar, ...) so that might not be possible.
(However also no methods can be declared on a TypedDict class so that might not be a problem?)
I read it completely and could not find anything
I asked here on typing-sig but did not yet get any responses.
gvanrossum commentedon Jun 21, 2021
Note that this issue is now only a problem of you use
from __future__ import annotations-- we rolled the default behavior for 3.10 back to what it was in 3.9.I am out of time to argue about why we chose this behavior, alas.
Kronuz commentedon Jul 3, 2021
The way I fixed this is I added
__forward_module__totyping.ForwardRef, so that it can resolve the forward reference with the same globals as the ones specified by the module in__forward_module__.TypedDict's metaclass should then pass the dictionary’s module name to the annotations’ forward references via the addedmodule’s keyword argument intyping._type_check(). I can work in a pull request with this solution and discuss any potential problems.Septatrix commentedon Jul 3, 2021
While this seems like a good solution I would still like to figure out why TypedDict do not preserve MRO. Because for now I have not found a reason nor did someone on the typing-sig mailinglist have a clue. Should there (no longer) be a reason for this then this problem has a trivial solution (just re-add the MRO and use that).
Kronuz commentedon Jul 3, 2021
Nils, unfortunately, fixing the MRO here won’t fix the issue because
TypedDict.__annotations__in the class copies the annotations from the parent classes, and when the type evaluation is made, it’s made using the copied annotation found in the bottommost class (which is thus then expected to be a forward reference in the same module as the class that inherited them. This producing the exact same problem of missing type.The most likely reason for incomplete MRO is that
TypeDictextends a class’__annotations__with all of it’s parent’s__annotations__, so the final class has the complete set of annotations of all of its parents, so having the full inheritance chain made less sense, after all the final dictionary class has all the annotations.Kronuz commentedon Jul 4, 2021
I added a pull request with my fix here:
#27017
gvanrossum commentedon Jul 17, 2021
New changeset 889036f by Germán Méndez Bravo in branch 'main':
bpo-41249: Fix postponed annotations for TypedDict (GH-27017)
889036f
gvanrossum commentedon Jul 17, 2021
How far can/should we backport this?
Fidget-Spinner commentedon Jul 17, 2021
It will work in 3.10 and 3.9 without issues. However, I don't remember if bugfixes for __future__ features require special treatment/are excluded from normal bugfix backports. I vaguely remember us not backporting from __future__ annotations very far back (since they usually broke backwards compatibility).
Maybe 3.10 is enough?
gvanrossum commentedon Jul 17, 2021
Let’s both, since this feels like a real bug fix to me.
ambv commentedon Jul 17, 2021
New changeset 480f29f by Miss Islington (bot) in branch '3.10':
bpo-41249: Fix postponed annotations for TypedDict (GH-27017) (bpo-27204)
480f29f
ambv commentedon Jul 17, 2021
New changeset fa674bd by Ken Jin in branch '3.9':
[3.9] bpo-41249: Fix postponed annotations for TypedDict (GH-27017) (GH-27205)
fa674bd
ambv commentedon Jul 17, 2021
Thanks! ✨ 🍰 ✨