Carl Meyer

@phistep I think that your "wrong and misleading in a different way" example would still be covered by #1584 -- we shouldn't map the unpacking to argument `d` when it...

This is definitely closely related to #136, but I'll keep it open as a separate sub-issue; the plan in #136 is to prefer the annotation over the inferred type in...

Yes, I think a different rule specific to this tuple case.

I don't at the moment have ideas of other cases where we'd want to apply such a rule. I think it's probably better if the rule is clear that it's...

I don't think ty "goes against a PEP" here. Interpreting an annotation of `float` as meaning `float | int` is one way to implement the (not very well specified) comment...

I'm going to reopen this issue to track whether we do need to do something differently to reduce user confusion here, because we get a lot of reports around this....

It is true that the spec only mentions arguments, but no type checker has ever interpreted the special case in that way (all type checkers are OK with your first...

Makes sense! Feel free to open another issue for that, though I'm not sure there is an obvious short-term resolution in ty, pending a clarification in the spec. If we...

Just want to note that the implementation here should generalize to providing these details for any assignability check between callables, not just for Liskov override checks specifically. That is, if...

> Note that the LSP does not apply to `Protocol` that's marked as `@final` If I understand correctly, you are describing a case like this? ```py from typing import Protocol,...