3.14 regression with `typing._eval_type()`

[Viicos]

Bug report

Bug description:

I'm in the process of adding 3.14 support to Pydantic. To evaluate type annotations, we make use of the private typing._eval_type() function. In an ideal we shouldn't, but this is very hard to change now (and still, we need evaluate "standalone" type expressions for several reasons, e.g. to be able to have TypeAdapter(list['ForwardReference']) working).

In 3.13, the following works:

from typing import ForwardRef, _eval_type


MyList = list[int]

MyDict = dict[str, 'MyList']


fw = ForwardRef('MyDict', module=__name__)

print(_eval_type(fw, globalns=None, localns=None, type_params=()))
#> dict[str, list[int]]

However, starting with 3.14, this raises:

from annotationlib import ForwardRef
from typing import _eval_type


MyList = list[int]

MyDict = dict[str, 'MyList']


fw = ForwardRef('MyDict', module=__name__)

print(_eval_type(fw, globalns=None, localns=None, type_params=()))
# NameError: name 'MyList' is not defined

Also explicitly passing globalns=globals() in 3.14 doesn't work, as typing._eval_type() is setting the globals to None if a __forward_module__ is present on the ForwardRef:

cpython/Lib/typing.py

Lines 432 to 447 in 5de7e3f

	def _eval_type(t, globalns, localns, type_params=_sentinel, *, recursive_guard=frozenset(),
	format=None, owner=None):
	"""Evaluate all forward references in the given type t.
	For use of globalns and localns see the docstring for get_type_hints().
	recursive_guard is used to prevent infinite recursion with a recursive
	ForwardRef.
	"""
	if type_params is _sentinel:
	_deprecation_warning_for_no_type_params_passed("typing._eval_type")
	type_params = ()
	if isinstance(t, _lazy_annotationlib.ForwardRef):
	# If the forward_ref has __forward_module__ set, evaluate() infers the globals
	# from the module, and it will probably pick better than the globals we have here.
	if t.__forward_module__ is not None:
	globalns = None

Which will affect all recursive calls to _eval_type() from evaluate_forward_ref().

---

Sorry I couldn't find a repro not relying on this private function (nor I could get rid of the explicit ForwardRef usage). Feel free to close as not planned, we can live without this in Pydantic (I hope).

cc @JelleZijlstra

CPython versions tested on:

3.14

Operating systems tested on:

No response

Linked PRs

• gh-136316: Make typing.evaluate_forward_ref better at evaluating nested forwardrefs #136319

[ZeroIntensity]

Hm, why can't Pydantic keep its own copy of _eval_type? I think that would be easier for everyone.

[Viicos]

This is something that I'm considering doing, although this function is quite "unstable" (in the sense that the implementation changes between each Python version). But we might even have to at some point, e.g. to make use of #131583 which prevents use from defining custom GenericAlias subclasses.

[Viicos]

Also it might be that the issue can be reproduced without using _eval_type() directly. After all, this function ends up being used by the public evaluation functions anyway.

[JelleZijlstra]

Ideally you should be using typing.evaluate_forward_ref for this, but it also raises on your example. Let's see if that can be fixed.

[JelleZijlstra]

#136319 fixes the issue in evaluate_forward_ref. It also fixes the issue with _eval_type you reported, though I'd still recommend you move away from that one.

[JelleZijlstra]

And please let me know if evaluate_forward_ref() isn't enough for you and you feel you still need to use _eval_type. I really want to move away from this situation where major libraries use private functions in typing.py.

[JelleZijlstra]

Also we're a few days away from ending the beta phase of Python 3.14, so any more invasive changes will have to come soon; we'll have to be much more careful once we're in the RC phase and beyond.