`get_type_hints` doesn't work properly with lambdas

[DetachHead]

Bug report

Bug description:

from __future__ import annotations

from typing import Annotated, cast, get_type_hints


class Foo:
    a: Annotated[int, lambda: cast]


get_type_hints(Foo, include_extras=True)["a"].__metadata__[0]() # NameError: name 'cast' is not defined

CPython versions tested on:

3.13

Operating systems tested on:

Windows

[JelleZijlstra]

If you want to introspect annotations, don't use an option to mangles them into strings (i.e., from __future__ import annotations).

This works correctly on 3.14 without the future import:

>>> from typing import Annotated, cast, get_type_hints
... 
... 
... class Foo:
...     a: Annotated[int, lambda: cast]
... 
... 
... get_type_hints(Foo, include_extras=True)["a"].__metadata__[0]() # NameError: name 'cast' is not defined
... 
<function cast at 0x103c037f0>

[DetachHead]

If you want to introspect annotations, don't use an option to mangles them into strings (i.e., from __future__ import annotations).

i don't get how this is a solution. that just sounds like "if you want the function to work, don't use a feature in the language that the function is supposed to work with"

sometimes it's necessary for type annotations to be strings, which i assume is why __future__.annotations was created in the first place. that was just a minimal example

[jorenham]

If you want to introspect annotations, don't use an option to mangles them into strings (i.e., from __future__ import annotations).

Is this specified somewhere?

[ericvsmith]

The problem with stringized annotations is that to convert them back to real types, you have to pass in the correct globals and/or locals to get_type_hints. It’s not always easy to get this right (as in the case of dataclasses). It’s one of the main motivators for the PEP 649.

[jorenham]

It’s not always easy to get this right (as in the case of dataclasses). It’s one of the main motivators for the PEP 649.

Let's see if I understand correctly, because I have the feeling that I'm missing something:

The reasoning is that you're not willing to fix acknowledge this bug, which is affecting all of the currently supported Python versions, is because

• fixing it difficult, and
• in the upcoming python 3.14 release, this problem can be avoided.

Did I get that right?

[JelleZijlstra]

That's about right.

The problem can be avoided in any release by not using from __future__ import annotations. That turns annotations into strings, which helps in two ways (it improves performance and avoids the need for quoting annotations manually) but hurts introspection. If you care about introspection, don't use that future import.

Maybe this can be fixed in some way by making get_type_hints() retrieve the right globals. But it already does a lot of weird things, and any change will likely also break something.

[jorenham]

Perhaps it would help to document this somewhere, as to help avoid others from running into the same problem?

[JelleZijlstra]

I am waiting for a decision on PEP-749 (likely soon), which will hopefully enable us to say with authority that the future import is deprecated.

[jorenham]

I am waiting for a decision on PEP-749 (likely soon), which will hopefully enable us to say with authority that the future import is deprecated.

But won't that deprecation only apply to >=3.14?

[tmr232]

I just ran into this a few days ago, and found it to be very confusing.
The documentation states

If globalns or localns is not given, appropriate namespace dictionaries are inferred from obj.

Since passing either globalns=sys.modules[Foo.__module__].__dict__ or localns=dict(vars(Foo)) seems to solve the issue, it feels like this should "just work".

Can we perhaps update the documentation to reflect this issue?