Assigning to intermediate variable changes type checking results · Issue #19304 · python/mypy · GitHub

Bug Report

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

# 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.

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

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]1 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.

due to the context Iterable[int | str] ↩

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

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.

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

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:

The type checker solves Vec[S | int] ≤ Iterable[int | str] and finds S ≤ int | str.
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.

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].

Another annoying example playground

def smallest_prefix(x: list[tuple[str, ...]]) -> str:
    return ".".join(min(x, key=len))  # false positive

main.py:2: error: Argument "key" to "min" has incompatible type "Callable[[Sized], int]"; expected "Callable[[Iterable[str]], SupportsDunderLT[Any] | SupportsDunderGT[Any]]"  [arg-type]

I put together a PR for this.

The bug seems to be that mypy uses the outer return context to specialize a generic callable before it has checked whether the actual arguments still fit that specialized signature.

In OP's Vec example, the outer context pushes the method toward something like:

(Vec[int | str]) -> Vec[int | str]

but the actual argument is still Vec[int]. So that contextual specialization is not a valid call. The same basic issue shows up in the recent min(..., key=...) example from @randolf-scholz : the return context can widen the item type enough that the key function no longer matches.

The PR keeps the existing contextual inference path, but adds a guard: if the context-specialized arguments are not compatible with the actual arguments, mypy can fall back to ordinary argument inference, as long as the ordinary inferred return type still satisfies the original outer context.

I had to keep this fairly narrow. In particular, constructors and special synthetic signatures keep the old behavior. Without that, tests like testAbstractTypeInADict failed, and some constructor/type-alias tests report worse Never-based messages.

Assigning to intermediate variable changes type checking results · Issue #19304 · python/mypy · GitHub

Repository navigation

Assigning to intermediate variable changes type checking results #19304

Applying to our case

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	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]),
	)

Assigning to intermediate variable changes type checking results · Issue #19304 · python/mypy · GitHub

Repository navigation

Assigning to intermediate variable changes type checking results #19304

Description

Activity

randolf-scholz commented on Jun 26, 2025

randolf-scholz commented on Jun 26, 2025

Footnotes

randolf-scholz commented on Jun 26, 2025

JelleZijlstra commented on Jun 26, 2025

randolf-scholz commented on Jun 26, 2025

randolf-scholz commented on Jun 26, 2025

Applying to our case

randolf-scholz commented on Jun 26, 2025

randolf-scholz commented on Mar 26, 2026

rheard commented on Aug 2, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions