Repository navigation
typing.get_type_hints() raises TypeError for a variable annotated by dataclasses.InitVar #88962
Description
Activity
I found
typing.get_type_hints()raises TypeError for a variable annotated bydataclasses.InitVarwhen lazy annotations evaluation-feature is enabled (a.k.a__future__.annotations).$ cat test.py from __future__ import annotations from dataclasses import dataclass, InitVar from typing import get_type_hints @dataclass class Foo: attr: InitVar[int] get_type_hints(Foo)$ python -V Python 3.9.6 $ python test.py Traceback (most recent call last): File "/Users/tkomiya/work/sphinx/test.py", line 10, in <module> get_type_hints(Foo) File "/Users/tkomiya/.pyenv/versions/3.9.6/lib/python3.9/typing.py", line 1424, in get_type_hints value = _eval_type(value, base_globals, localns) File "/Users/tkomiya/.pyenv/versions/3.9.6/lib/python3.9/typing.py", line 290, in _eval_type return t._evaluate(globalns, localns, recursive_guard) File "/Users/tkomiya/.pyenv/versions/3.9.6/lib/python3.9/typing.py", line 545, in _evaluate type_ =_type_check( File "/Users/tkomiya/.pyenv/versions/3.9.6/lib/python3.9/typing.py", line 164, in _type_check raise TypeError(f"{msg} Got {arg!r:.100}.") TypeError: Forward references must evaluate to types. Got dataclasses.InitVar[int].It goes well if lazy annotations evaluation is disabled.
- added3.8 (EOL)end of lifeend of life3.10 (EOL)end of lifeend of life3.9 (EOL)end of lifeend of lifestdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on Jul 31, 2021 I think this should be fixed in typing.py instead. get_type_hints() should be less strict about what it accepts as a type, so users are free to use annotations in innovative ways.
Static type checkers should have the job of enforcing that type annotations are valid types.
This is now fixed in main thanks to bpo-46644:
>>> get_type_hints(Foo) {'attr': dataclasses.InitVar[int]}We're not backporting that change to the bugfix branches. If we want to fix this issue in 3.10 and 3.9, we'll have to add a
__call__method toInitVar. My inclination is that that's not worth it.Reacted by Finite State MachineI agree it's not worth fixing in 3.9 and 3.10.
Reacted by Finite State Machine
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:
bugs.python.org fields: