Skip to content

typing.get_type_hints() raises TypeError for a variable annotated by dataclasses.InitVar #88962

Description

@tk0miya
mannequin
BPO 44799
Nosy @ericvsmith, @JelleZijlstra, @uriyyo, @tk0miya
PRs
  • bpo-44799: Fix InitVar resolving using get_type_hints #27553
  • 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 = 'https://github.com/ericvsmith'
    closed_at = <Date 2022-03-12.18:00:32.186>
    created_at = <Date 2021-07-31.17:19:44.535>
    labels = ['library', '3.9', '3.10']
    title = 'typing.get_type_hints() raises TypeError for a variable annotated by dataclasses.InitVar'
    updated_at = <Date 2022-03-12.18:00:32.185>
    user = 'https://github.com/tk0miya'

    bugs.python.org fields:

    activity = <Date 2022-03-12.18:00:32.185>
    actor = 'JelleZijlstra'
    assignee = 'eric.smith'
    closed = True
    closed_date = <Date 2022-03-12.18:00:32.186>
    closer = 'JelleZijlstra'
    components = ['Library (Lib)']
    creation = <Date 2021-07-31.17:19:44.535>
    creator = 'tkomiya'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 44799
    keywords = ['patch']
    message_count = 4.0
    messages = ['398650', '411228', '414969', '414974']
    nosy_count = 4.0
    nosy_names = ['eric.smith', 'JelleZijlstra', 'uriyyo', 'tkomiya']
    pr_nums = ['27553']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue44799'
    versions = ['Python 3.9', 'Python 3.10']

    Activity

    1. tk0miya commented on Jul 31, 2021

      tk0miyamannequin
      MannequinAuthor

      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.

    2. added
      stdlibStandard Library Python modules in the Lib/ directory
      on Jul 31, 2021
    3. JelleZijlstra commented on Jan 22, 2022

      @JelleZijlstra
      Member

      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.

    4. JelleZijlstra commented on Mar 12, 2022

      @JelleZijlstra
      Member

      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.

    5. ericvsmith commented on Mar 12, 2022

      @ericvsmith
      Member

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

    6. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    3.10 (EOL)end of life3.9 (EOL)end of lifestdlibStandard Library Python modules in the Lib/ directory

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions