Assigning to intermediate variable changes type checking results

[randolf-scholz]

Bug Report

• Assigning to an intermediate variable can change inference results.
• Incorrect inference when inside a function call.

mypy-playground

# mypy: disable-error-code=empty-body
# fmt: off
from typing import Iterable, Iterator

class Vec[T]:  # proxy for list[T]
    def getitem(self, i: int) -> T: ...            # ensure invariance of T
    def setitem(self, i: int, v: T) -> None: ...   # ensure invariance of T
    def __init__(self, iterable: Iterable[T], /) -> None: ...
    def __iter__(self) -> Iterator[T]: ...
    def __add__[S](self, value: "Vec[S]", /) -> "Vec[S | T]": ...

def fmt(arg: Iterable[int | str]) -> None: ...  # <-- union plays a role

l1: Vec[int] = Vec([1])
l2: Vec[int] = Vec([1])
fmt(l1 + l2)  # ❌ Unsupported operand types for + ("Vec[int]" and "Vec[int]")

dummy = l1 + l2
fmt(dummy)  # ✅

Same example without PEP 695

https://mypy-play.net/?mypy=latest&python=3.12&gist=43a91e52a767ac27f2706795d45bdef1

# mypy: disable-error-code=empty-body
# fmt: off
from typing import TypeVar, Generic, Iterable, Iterator

T = TypeVar("T")
S = TypeVar("S")

class Vec(Generic[T]):
    def getitem(self, i: int) -> T: ...            # ensure invariance of T
    def setitem(self, i: int, v: T) -> None: ...   # ensure invariance of T
    def __init__(self, iterable: Iterable[T], /) -> None: ...
    def __iter__(self) -> Iterator[T]: ...
    def __add__(self, value: "Vec[S]", /) -> "Vec[S | T]": ...

def fmt(arg: Iterable[int | str]) -> None: ...

l1: Vec[int] = Vec([1])
l2: Vec[int] = Vec([1])
fmt(l1 + l2)  # ❌ Unsupported operand types for + ("Vec[int]" and "Vec[int]")

dummy = l1 + l2
fmt(dummy)  # ✅

original bug report

Bug Report

I was testing this PR (python/typeshed#14283) for typeshed that simplifies list.__add__ from

@overload
def __add__(self, value: list[_T], /) -> list[_T]: ...
@overload
def __add__(self, value: list[_S], /) -> list[_S | _T]: ...

to

def __add__(self, value: list[_S], /) -> list[_S | _T]: ...

This seems to work generally, but there are some weird circumstances when it bugs out. It seems most of them appear when a concatenation is given as an argument to another function.

As an example, this is one of the lines that gets flagged:

mypy/mypyc/crash.py

Line 29 in 5081c59

for s in traceback.format_list(tb + tb2):

However, mypy stops complaing if it is changed to

dummy = tb + tb2
for s in traceback.format_list(dummy):

Assigning to an intermediate variable changed the type checking results (!)

I couldn't reproduce this behavior using a custom class, which makes me believe this is probably due to some weird special casing for builtins.

To Reproduce

git clone --branch polymorphic_overload_test https://github.com/randolf-scholz/typeshed.git
git clone https://github.com/python/mypy.git
cd typeshed
uv venv --seed
source .venv/bin/activate
uv pip install -r requirements-tests.txt
mkdir tmp
cp ../mypy/mypyc/crash.py tmp/tmp.py
python -m mypy.stubtest --custom-typeshed-dir=../typeshed tmp

Expected Behavior

Assigning to an intermediate variable shouldn't affect type inference.

[randolf-scholz]

EDIT: I was able to reproduce it with PEP 695 syntax and updated the OP accordingly.

[randolf-scholz]

I believe this is the code responsible for the problem:

mypy/mypy/checkexpr.py

Lines 1772 to 1799 in 5e9d657

	if callee.is_generic():
	need_refresh = any(
	isinstance(v, (ParamSpecType, TypeVarTupleType)) for v in callee.variables
	)
	callee = freshen_function_type_vars(callee)
	callee = self.infer_function_type_arguments_using_context(callee, context)
	if need_refresh:
	# Argument kinds etc. may have changed due to
	# ParamSpec or TypeVarTuple variables being replaced with an arbitrary
	# number of arguments; recalculate actual-to-formal map
	formal_to_actual = map_actuals_to_formals(
	arg_kinds,
	arg_names,
	callee.arg_kinds,
	callee.arg_names,
	lambda i: self.accept(args[i]),
	)
	callee = self.infer_function_type_arguments(
	callee, args, arg_kinds, arg_names, formal_to_actual, need_refresh, context
	)
	if need_refresh:
	formal_to_actual = map_actuals_to_formals(
	arg_kinds,
	arg_names,
	callee.arg_kinds,
	callee.arg_names,
	lambda i: self.accept(args[i]),
	)

Due to the callee = self.infer_function_type_arguments_using_context(...), the result of Vec[int] + Vec[int] is inferred as Vec[int | str]¹ instead of Vec[int], and then later check_argument_types fails because of that.

If we were to swap and do callee = self.infer_function_type_arguments(...) before callee = self.infer_function_type_arguments_using_context(...) then this bug disappears. However, it would cause lots of other things to break, such as assignments like x: list[object] = [1,2,3].

@JelleZijlstra any pointers on how this could be fixed? It is a rather annoying bug that prevents doing some useful simplifications in typeshed.

Footnotes

1. due to the context Iterable[int | str] ↩

[randolf-scholz]

My gut feeling is that this code should first try checking without context, and only if that fails, consider the context as well.

[JelleZijlstra]

It's generally expected that type checking may behave differently when assigning to an intermediate variable (due to type context). It's possible that we can improve the heuristics here, but there's a big risk that we'll make other cases worse. I don't have much knowledge of the tradeoffs made within mypy here but you're welcome to try out some options.

I wouldn't expect things to behave differently depending on whether you use old-style or PEP 695 generics; there might be a bug there.

[randolf-scholz]

PEP 695 doesn't make a difference, the difference I saw earlier was because I didn't ensure invariance in T in the example, and it made it covariant with PEP 695

[randolf-scholz]

So with this type context stuff as far as I understood it after some debugging is that we want to allow:

x: list[object] = [x for x in [1,2,3]]

Which without context would fail, since list[T] is invariant in T and the RHS would evaluate to list[int].
However, since int is assignable to object, we are allowed to insert an upcast:

x: list[object] = [cast(object, x) for x in [1,2,3]]

Or, equivalently, we could consider putting a lower bound on the type variable in the constructor

# original only has upper bound
def list_comprehension[T ≤ object](arg: T) -> list[T]: ...
# we can consider the restriction
def list_comprehension[object ≤ T ≤ object](arg: T) -> list[T]: ...

Applying to our case

In the OP example, this fails as follows:

1. The type checker solves Vec[S | int] ≤ Iterable[int | str] and finds S ≤ int | str.
2. However, Vec[int] is not assignable to Vec[int | str], therefore the upcasting is not valid in this case!

---

Therefore, to solve the bug, inferring from context is only OK if the original arguments are assignable to the upcasted types.

[randolf-scholz]

Shower-thought: I wonder if one could get rid of this context completely by using something similar to interval-arithmetic. Instead of returning a singular type, consider returning a typevar that is constrained to the range of possible values one could obtain by upcasting the arguments. e.g. for [x for x in [1,2,3]] we would get the interval T∈[int, object], and then voila, the result is assignable to list[object].