Fix thread-safety of interpreter cached object str_replace_inf (free threading)

[colesbury]

Bug report

We have a number of per-interpreter cached objects. Some of these are lazily initialized in a way that is not thread-safe in the free threading build. (See #125221, for example).

We should go through the remaining ones and make sure they are thread-safe.

EDIT: The only remaining field is str_replace_inf. Accesses to type_slots_pname and type_slots_ptrs are protected by a lock and the TypeVar fields are initialized once early on with other types.

cpython/Include/internal/pycore_global_objects.h

Lines 63 to 85 in 01fc3b3

	#define _Py_INTERP_CACHED_OBJECT(interp, NAME) \
	(interp)->cached_objects.NAME
	struct _Py_interp_cached_objects {
	PyObject *interned_strings;
	/* AST */
	PyObject *str_replace_inf;
	/* object.__reduce__ */
	PyObject *objreduce;
	PyObject *type_slots_pname;
	pytype_slotdef *type_slots_ptrs[MAX_EQUIV];
	/* TypeVar and related types */
	PyTypeObject *generic_type;
	PyTypeObject *typevar_type;
	PyTypeObject *typevartuple_type;
	PyTypeObject *paramspec_type;
	PyTypeObject *paramspecargs_type;
	PyTypeObject *paramspeckwargs_type;
	PyTypeObject *constevaluator_type;
	};

Linked PRs

• gh-125268: Use static string for "1e309" in AST #125272
• [3.13] gh-125268: Use static string for "1e309" in AST (GH-125272) #125280

[colesbury]

The "TypeVar and related types" fields are initialized during interpreter start-up, so they're fine.