I found `typing.get_type_hints()` raises TypeError for a variable annotated by `dataclasses.InitVar` when 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.

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 to `InitVar`. My inclination is that that's not worth it.

I agree it's not worth fixing in 3.9 and 3.10.

pull_requests: + pull_request26060
stage: patch review