pyre-check
pyre-check copied to clipboard
Find lambdas are not checked correctly
Pyre Bug
Bug description Please enter a clear and concise description of what the bug is.
I use filter
function to filter out None
values in a second value of sequence of pairs (tuple
is used for the pair class).
With pyre-check 0.9.19
and Python 3.12.0 I have following error which is not correct as I filter out None values (value[1] is not None
as shown below)
test.py:5:4 Incompatible return type [7]: Expected `Iterable[Tuple[str, str]]` but got `filter[Tuple[str, Optional[str]]]`.
Reproduction steps
Enter steps to reproduce the behavior.
I created an empty virtualenv, created a file test.py
in empty folder with contents as shown below and run pyre
from collections import abc
def filter_none(
values: abc.Sequence[tuple[str, str | None]]
) -> abc.Iterable[tuple[str, str]]:
return filter(lambda value: value[1] is not None, values)
Expected behavior Give a clear and concise description of what you expected to happen.
Logs Please include any relevant logs here:
Output goes here
Please run your reproduction steps followed by pyre rage > pyre_rage.log
, and upload the file here:
Additional context Add any other context about the problem here. (like dependencies in your venv, third party stub files being used, overall goals, etc.)
Hi! It looks like you're facing a type-checking issue with Pyre when filtering tuples that might contain None
in their second element. Pyre seems to struggle with inferring that after filtering, the second element of the tuples is indeed always a string and not None
. Normally, you'd expect Pyre to recognize that the lambda function ensures no None
values remain in the second element, so the output should be Iterable[Tuple[str, str]]
. However, it incorrectly interprets it as Iterable[Tuple[str, Optional[str]]]
. A practical workaround is to use a list comprehension instead of the filter function. This alternative approach usually provides clearer type hints that help static analysis tools like Pyre understand the intended types more accurately.