Misleading error message with `dict.get` like method. (polymorphic function with conflicting context)

[randolf-scholz]

Consider this example that emulates dict.get: (https://mypy-play.net/?mypy=latest&python=3.12)

from typing import Any, reveal_type

class Map[K, V]:
    def set(self, key: K, value: V) -> None: ...
    def get[T](self, key: Any, default: T, /) -> V | T: ...

d_any: Map[str, Any] = Map()

reveal_type(d_any.get("key", None))  # Any | None  ✅️

result: str = reveal_type(d_any.get("key", None))  # Any | str ❌️
# error: Argument 2 to "get" of "Map" has incompatible type "None"; expected "str" 

mypys error message is misleading. None is a perfectly reasonable argument for the default value of d_any.get. The problem is that the return type Any | None is not assignable to str. It would make more sense if either:

1. mypy reports that Any | None cannot be assigned to str.
   (e.g. by a two step approach: first try to solve with context and if that fails, use the return type that is inferred from the arguments alone)¹
2. mypy reports that it cannot find a solution for the type variable T.
   (e.g. single step that considers both constraints from arguments and context)

Footnotes

1. In certain special cases like tuple/list/set/dict-comprehensions, the current behavior that inverts the priority seems fine ↩

[ayushjariyal]

@randolf-scholz, I want to work on this issue. Could you please assign it to me?
I am very thankful if you guide me how to approach this as I am new to this organization.

[sterliakov]

@ayushjariyal I'd recommend you browse good-first-issue and good-second-issue tickets first. Type context fun in inference might not be the best place to start getting to know mypy codebase. Anyway, feel free to work on this if you feel like, we don't assign tickets here - you can just start working and submit a PR when ready.

[randolf-scholz]

I believe solving this will be rather complex, so this is likely not a good first issue to work on.

To be a bit more specific, I believe this will require a major refactor of check_callable_call.
I actually have spent quite a lot of time myself trying to fix similar issues (you can check my unfinished work randolf-scholz#4, and earlier version #19399.

However, this work is blocked as some other issues need to fixed first: specifically issues linked in #20472 and #20444.

[randolf-scholz]

In fact, testing this issue on PR randolf-scholz#4 actually gives us the outcome of option (2).