list comprehensions: mypy fails to derive the union type for lists but not for tuples

[anilbey]

Bug Report

Inside a list comprehension mypy fails to derive the union type for lists but not for tuples.

To Reproduce

a = 5
b = "a_string"
list1: list[int | str] = [x for x in (a, b)]  # works
list2: list[int | str] = [x for x in [a, b]]  # fails

Expected Behavior

The same type should be derived for both lists.

Actual Behavior

The first list is recognised as list[int | str],
The second list is recognised as list[object],
Hence the error on line 4

❯ mypy mypy-repro.py                                                                                                                                                                                                               ─╯
mypy-repro.py:4: error: List comprehension has incompatible type List[object]; expected List[int | str]  [misc]
Found 1 error in 1 file (checked 1 source file)

Your Environment

❯ python --version                                                                                                                                                                                                                 ─╯
Python 3.11.8

❯ pip list | grep mypy                                                                                                                                                                                                             ─╯
mypy                  1.13.0
mypy-extensions       1.0.0

[anilbey]

Note, it works for int and float types.

a = int(5)
b = float(3.14)
list1: list[int | float] = [x for x in (a, b)]  # works
list2: list[int | float] = [x for x in [a, b]]  # works

[anilbey]

It does not work however on other objects.

class A:
    pass

class B:
    pass


a = A()
b = B()

# This list comprehension works
l2: list[A | B] = [x for x in (a, b)]

# This list comprehension causes a mypy error
l3: list[A | B] = [x for x in [a, b]]

mypy-repro.py:15: error: List comprehension has incompatible type List[object]; expected List[A | B]  [misc]
Found 1 error in 1 file (checked 1 source file)

[allenpinjic]

Hi there! Both @EECSStudent1 and I have worked on this issue recently and we believe we know where part of the issue is being reproduced after some additional testing that builds off of the report by @anilbey.

With tests that factor in greater number combinations of datatypes for both lists and tuples, we noticed that mypy specifically seems to fail to derive the union type when strings are accepted by a list and are not the only given datatype (building off of @anilbey’s observations).

a = 5
b = "astring"
c = "bstring"
d = True
e = 'c'
f = 2.2
# With tuples
list1: list[int | str] = [x for x in (a, b)]
list2: list[str | bool] = [x for x in (b, d)]
list3: list[str | float] = [x for x in (b, f)]
list4: list[str | str] = [x for x in (b, c)]
list5: list[int | bool] = [x for x in (a, d)]
list6: list[float | bool] = [x for x in (f, d)]
list7: list[int | float] = [x for x in (a, f)]
# With lists
list8: list[int | str] = [x for x in [a, b]]  # fails
list9: list[str | bool] = [x for x in [b, d]]  # fails
list10: list[str | float] = [x for x in [b, f]]  # fails
list11: list[str | str] = [x for x in [b, c]]
list12: list[int | bool] = [x for x in [a, d]]
list13: list[float | bool] = [x for x in [f, d]]
list14: list[int | float] = [x for x in [a, f]]

Generating these errors:

mypy-repo.py:20: error: List comprehension has incompatible type List[object]; expected List[int | str]  [misc]
mypy-repo.py:21: error: List comprehension has incompatible type List[object]; expected List[str | bool]  [misc]
mypy-repo.py:23: error: List comprehension has incompatible type List[object]; expected List[str | float]  [misc]
Found 3 errors in 1 file (checked 1 source file)

Furthermore, when testing with a list that does not have a specified Union type no error is produced by mypy:

a = 5
b = "astring"
list1: list = [x for x in [a, b]]
list2: list[int | str] = [x for x in [a, b]]  # fails

mypy-repo.py:9: error: List comprehension has incompatible type List[object]; expected List[int | str]  [misc]
Found 1 error in 1 file (checked 1 source file)

As we understood it, the issue is occurring since list2 is declared with Union-type [string | ‘insert’], causing it to return an error as the best overall supertype of the list is always calculated by mypy to be a builtins.object. However, while a builtins.object is also calculated to be the best supertype for an ordinary list (aka. list1), it does not return an error since the list type is never explicitly stated and therefore the return type does not seem to be relevant.

[allenpinjic]

This calculation can be found when checking the list expression via fast_container_type() in checkexpr.py, where join_type_list() calls join_instances() and join_instances_via_supertype() in join.py to compute the best supertype when considering the two datatypes of the variables present in the list (ie. a and b).

Using a visual debugger on the “seen_instances” and “best” data structures within join_instances(), we seem to capture how the supertype is ultimately calculated, (and therefore the builtins.object which causes the issues previously mentioned):

Union type list (int and bool - aka. the control scenario):
"list0: list[int | bool] = [x for x in [5, True]]”

best = builtins.int
seen_instances = {list: 2} [(Literal[True]?, Literal[5]?), (builtins.int, Literal[5]?)]
 0 = {tuple: 2} (Literal[True]?, Literal[5]?)
 1 = {tuple: 2} (builtins.int, Literal[5]?)

Union type list (including string):
“list2: list[int | str] = [x for x in [a, b]]”:

best =  builtins.object
seen_instances = {list: 7} [(builtins.str, builtins.int), (builtins.float, builtins.str), (typing.Sequence[builtins.str], builtins.float), (builtins.complex, typing.Sequence[builtins.str]), (typing.Collection[builtins.str], builtins.complex), (builtins.object, typing.Collection[builtins.str]), (typing.Iterable[builtins.str], builtins.object)]
 0 = {tuple: 2} (builtins.str, builtins.int)
 1 = {tuple: 2} (builtins.float, builtins.str)
 2 = {tuple: 2} (typing.Sequence[builtins.str], builtins.float)
 3 = {tuple: 2} (builtins.complex, typing.Sequence[builtins.str])
 4 = {tuple: 2} (typing.Collection[builtins.str], builtins.complex)
 5 = {tuple: 2} (builtins.object, typing.Collection[builtins.str])
 6 = {tuple: 2} (typing.Iterable[builtins.str], builtins.object)

Non-union type list (including string):
“list1: list = [x for x in [a, b]]”:

best =  builtins.object
seen_instances = {list: 7} [(builtins.str, builtins.int), (builtins.float, builtins.str), (typing.Sequence[builtins.str], builtins.float), (builtins.complex, typing.Sequence[builtins.str]), (typing.Collection[builtins.str], builtins.complex), (builtins.object, typing.Collection[builtins.str]), (typing.Container[builtins.str], builtins.object)]
 0 = {tuple: 2} (builtins.str, builtins.int)
 1 = {tuple: 2} (builtins.float, builtins.str)
 2 = {tuple: 2} (typing.Sequence[builtins.str], builtins.float)
 3 = {tuple: 2} (builtins.complex, typing.Sequence[builtins.str])
 4 = {tuple: 2} (typing.Collection[builtins.str], builtins.complex)
 5 = {tuple: 2} (builtins.object, typing.Collection[builtins.str])
 6 = {tuple: 2} (typing.Container[builtins.str], builtins.object)

Because of the way in which join_instances() seems to conflict with the assumptions made by what objects are considered legal for Union-type lists, it might be necessary to modify the ways in which some functions are called in order to accurately derive the Union-type for a list (or at least ones with strings). In the same regard, it might also be necessary to see what differentiates the ways in which tuples are evaluated vs lists since it might further shed light on what to change.

However, due to @AlexWaygood informing us of the complexity of this issue (which would involve changing a lot of long-standing inference that mypy users rely on) and our own inability to continue working on this issue in the future we wanted to at least provide our findings here for anyone else who decides to pick up where we left off.

Also apologies if there are any conceptual errors on our part. We just wanted to provide some of the information which we found while attempting to solve this issue. This would have been be our first contribution to an open-source project so we were still attempting to try and find the best approach to help solve this problem.

Best of luck to anyone else continuing with these and other related issues!