astral-sh
`Iterable[list[int]]` as type context is not handled well
Summary
In this snippet:
from typing import reveal_type, Iterable
x: Iterable[list[int]] = [[42], [56]]
reveal_type(x)
we currently reveal list[Unknown | list[Unknown | int]]. For comparison, mypy and pyrefly reveal Iterable[list[int]] and pyright reveals list[list[int]]. Either seems better than our current answer (though I like pyright's best!).
cc. @ibraheemdev
Version
No response
In general, we currently only consider type context if the types are equivalent. We probably need to extend this to a subclass check (and infer the correct type arguments).
@ibraheemdev does this example fall into the category of "needs new constraint solver"?
https://play.ty.dev/68b3e41b-7eee-4658-ae20-3a2b0f59fb7d
from collections.abc import Mapping
from typing import Literal
def process(data_types: Mapping[str, Literal["BOOL", "INT", "FLOAT"]], /) -> None:
...
process({"foo":"BOOL"})
(We handle it fine if it is Mapping[str, str], but not with the union of literals)
@carljm that one should also be fixed by https://github.com/astral-sh/ruff/pull/21930.