You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
main.py:6: error: Item "int" of "int | str" has no attribute "upper" [union-attr]
main.py:16: error: Argument 1 to "assert_never" has incompatible type "int | str"; expected "Never" [arg-type]
Found 2 errors in 1 file (checked 1 source file)
That was introduced in #16503. I guess it should be possible to rewrite that name generation logic to make it work with any expression, not only a simple call.
@tyralla yep, I'll try to get this done soon. I think I can (at a reasonably low cost of just keeping a last_used_id per TypeChecker) handle that for arbitrary expressions in match without trying to specialize for any specific one. That would also allow narrowing of immediately-constructed tuples/lists/dicts/sets (with tuple being probably the most popular pattern), and maybe some other expressions I didn't think of yet.
We can also try to extend this spaghetti one-by-one for call, index, tuple, list, ... expressions, but I don't think it's the most ergonomic solution. This id shouldn't ever leak to error messages, so IMO just f"dummy-match-{self.last_used_id}" is a perfect candidate.
Activity
tyralla commentedon Jan 10, 2025
Thanks for the report!
The first example is not a bug. Consider this example:
However, the second example is in fact a limitation:
sterliakov commentedon Jan 10, 2025
And the second part happens because only calls are currently considered "special enough", and an IndexExpr is not a CallExpr:
mypy/mypy/checker.py
Lines 5272 to 5284 in 106f714
That was introduced in #16503. I guess it should be possible to rewrite that name generation logic to make it work with any expression, not only a simple call.
tyralla commentedon Jan 10, 2025
@sterliakov: Cool, do you plan to extend "this hack"? I was starting to do it, but only have the test case so far:
Feel free to take it, if this small snippet seems useful.
sterliakov commentedon Jan 10, 2025
@tyralla yep, I'll try to get this done soon. I think I can (at a reasonably low cost of just keeping a last_used_id per
TypeChecker) handle that for arbitrary expressions inmatchwithout trying to specialize for any specific one. That would also allow narrowing of immediately-constructed tuples/lists/dicts/sets (with tuple being probably the most popular pattern), and maybe some other expressions I didn't think of yet.We can also try to extend this spaghetti one-by-one for call, index, tuple, list, ... expressions, but I don't think it's the most ergonomic solution. This id shouldn't ever leak to error messages, so IMO just
f"dummy-match-{self.last_used_id}"is a perfect candidate.injust commentedon Jul 26, 2025
Here's another test case, which doesn't use
dict:It's a simplified version of what I reported in #18875.
Introduce temporary named expressions for `match` subjects (#18446)