Repository navigation
Incorrect errors for fstrings + generators #3385
Description
mypy version: 0.511
python version: 3.6.1
Given this valid program:
from typing import Iterator
def stringify(it: Iterator[int]) -> Iterator[str]:
return (f"{x}" for x in it)
def stringify2(it: Iterator[int]) -> Iterator[str]:
for x in it:
yield f"{x}"
def stringify3(it: Iterator[int]) -> Iterator[str]:
return (str(x) for x in it)
def stringify4(it: Iterator[int]) -> Iterator[str]:
for x in it:
yield str(x)I get errors for the first two variations:
foo.py:4: error: Generator has incompatible item type "int"
foo.py:8: error: Incompatible types in yield (actual type "int", expected type "str")
It seems that mypy doesn't recognize that fstrings are produce a str. Interestingly, the yield error didn't show up in my old mypy version 0.501.
Activity
ns-cweber commentedon May 19, 2017
Strangely, this is fine:
... but this is not:
So it seems like it's the unpacking syntax (
... for x, y in ...) that makes the difference, and not whether or not the iterator type is primitive.[-]Incorrect errors for new fstrings[/-][+]Incorrect errors for fstrings + generators[/+]ns-cweber commentedon May 19, 2017
It looks like it doesn't have anything to do with the unpacking; it seems to pertain to the handling of
ast.FormattedValue. Mypy handles this correctly:According to GreenTreeSnakes' FormattedValue docs:
In this most recent example, using an fstring with tokens besides the formatted value produces a JoinedStr token. Maybe mypy handles JoinedStr correctly but not FormattedValue?
JelleZijlstra commentedon May 19, 2017
Yes, it looks like the bug is that mypy interprets
f"{x}"as having the type ofx.Parse each format-string component separately
Parse each format-string component separately
Parse each format-string component separately (#3390)