failure to simplify `Iterable[T] & tuple[object, ...]` to `tuple[T, ...]`

[h3har]

ty 0.0.55 (42869400d 2026-06-26) does not narrow an Iterable[T] type to tuple[T, ...] when an instance check is performed against tuple. I assume this also demonstrates a more general issue of simplifying similar intersections.

ty example

from typing import Iterable, reveal_type

def f(values: Iterable[int]):
    if isinstance(values, tuple):
        reveal_type(values) # revealed: Iterable[int] & tuple[object, ...]
    else:
        reveal_type(values) # revealed: Iterable[int] & ~tuple[object, ...]

pyright example

On the other hand, pyright reveals the following types:

from typing import Iterable, reveal_type

def f(values: Iterable[int]):
    if isinstance(x, tuple):
        reveal_type(x) # revealed: tuple[int, ...]
    else:
        reveal_type(x) # revealed: Iterable[int]

Why this is a problem

Here is a simplified example of a downstream false positive type error that I encountered:

from typing import Iterable, reveal_type

def g(values: Iterable[int]):
    if not isinstance(values, tuple):
        values = tuple(values)
    reveal_type(values[1:-1]) # revealed: tuple[object, ...]
    return (0, *(x + 1 for x in values[1:-1]), 0)

ty output:

info[revealed-type]: Revealed type
 --> test.py:6:17
  |
6 |     reveal_type(values[1:-1]) # revealed: tuple[object, ...]
  |                 ^^^^^^^^^^^^ `tuple[object, ...]`
  |

error[unsupported-operator]: Unsupported `+` operation
 --> test.py:7:18
  |
7 |     return (0, *(x + 1 for x in values[1:-1]), 0)
  |                  -^^^-
  |                  |   |
  |                  |   Has type `Literal[1]`
  |                  Has type `object`
  |

Found 2 diagnostics

[sharkdp]

Thank you for reporting this.

I think this broadly falls into the category of #1578, because in principle, there could be a tuple subclass that is an Iterable[int] (and so it would be a valid argument to this function AND pass the isinstance(.., tuple) check), but is not a subtype of tuple[int, ...]? Maybe that would be a Liskov violation though, so I think it's reasonable to consider this simplification proposed here.

We're also going to make changes to isinstance narrowing soon that would make ty's behavior here less strict (by default). That would also solve the unsupported-operator diagnostic that you're seeing. Instead of intersecting with tuple[object, ...], we would then intersect with tuple[Unknown, ...].

[h3har]

@sharkdp

I've also noticed that a similar issue is observed for lists as well as tuples:

from typing import Iterable, reveal_type

def f(values: Iterable[int]):
    if isinstance(values, list):
        reveal_type(values) # revealed: Iterable[int] & Top[list[Unknown]]
        reveal_type(values[1:-1]) # revealed: list[Never]

Given that isinstance(values, list) seems to intersect with Top[list[Unknown]] and yet still produce a seemingly incorrect result list[Never], it's not obvious to me that the isinstance change you referenced above would fully resolve the issue.

[sharkdp]

Given that isinstance(values, list) seems to intersect with Top[list[Unknown]] and yet still produce a seemingly incorrect result list[Never],

Thank you. I reported this separately as #3903

it's not obvious to me that the isinstance change you referenced above would fully resolve the issue.

I can confirm that the errors in of your examples would go away with astral-sh/ruff#26472. It's not the ideal solution though, since you would get Iterable[int] & tuple[Unknown, ...] instead of tuple[int, ...]. Iterating over this would yield int & Unknown instead of int. So the intersection simplification proposed here still makes sense. A similar case is already tracked in #1824, I added a comment there.

I will close this issue when astral-sh/ruff#26472 gets merged.