Oct 14, 2025 · Aug 11, 2025 · Sep 21, 2025 · Sep 22, 2025 · Sep 22, 2025 · Sep 23, 2025
diff --git a/mypy/checkmember.py b/mypy/checkmember.py
        str_type = mx.chk.named_type("builtins.str")
        fn_type = mx.chk.named_type("builtins.function")
        object_type = mx.chk.named_type("builtins.object")

        type_info = typ.fallback.type
        # type variable for default value
        tvar = TypeVarType(
            "T",
 "T",
            id=TypeVarId(-1),
 f"{type_info.fullname}.get.T",
            id=TypeVarId(-1, namespace=f"{type_info.fullname}.get"),
            values=[],
            upper_bound=object_type,
            default=AnyType(TypeOfAny.from_omitted_generics),
Original file line number	Diff line number	Diff line change
Expand Up		@@ -1409,12 +1409,12 @@ def analyze_typeddict_access(
		str_type = mx.chk.named_type("builtins.str")
		fn_type = mx.chk.named_type("builtins.function")
		object_type = mx.chk.named_type("builtins.object")

		type_info = typ.fallback.type
		# type variable for default value
		tvar = TypeVarType(
Copy link Collaborator sterliakovSep 23, 2025• edited Loading Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. I'm not sure that`TypeVarType` should ever be introduced without a corresponding symbol (`TypeVarExpr`). Any other place that needs to synthesize persistent (not single-use like a fake constructor in checkexpr) typevars does so in two steps (grep for`TypeVarExpr` in`semanal_namedtuple.py` or dataclasses plugin). I suspect that some nasal demons are expected if`TypeVarType` isn't anchored to some real symbol, this might bite us later.
		"T",
		"T",
		id=TypeVarId(-1),
		f"{type_info.fullname}.get.T",
		id=TypeVarId(-1, namespace=f"{type_info.fullname}.get"),
		values=[],
		upper_bound=object_type,
		default=AnyType(TypeOfAny.from_omitted_generics),
Expand Down