use is_same_type when resolving decorators in suggestions

[asottile]

followup to https://github.com/python/mypy/pull/19072/files/55ef5994102771f07cfe30b2123c4de22c7a2869#r2083298219

[asottile]

this does seem to have a strange side-effect that I can't quite wrap my head around

using this sample code:

from __future__ import annotations

from typing import Callable, Protocol, TypeVar, Any
from typing_extensions import ParamSpec, TypeAlias

def dec(f: Callable[..., Any]) -> Callable[..., Any]:
    return f

@dec
def f(x, y):
    return x + y

f(1, 2)

before this produced "Object t.f is a decorator we can't handle"

but now it produces:

(int, Any) -> Any

(a correct decorator allows it to infer (int, int) -> int but I am quite confused how it figured out one of the parameters but not both and then not the return value 🤔)

[JelleZijlstra]

Is the code sample in your last message correct? I don't get that error in the playground when I try the code in your message, but maybe you meant something else. You imported ParamSpec but didn't use it.

[asottile]

Is the code sample in your last message correct? I don't get that error in the playground when I try the code in your message, but maybe you meant something else. You imported ParamSpec but didn't use it.

yeah the imports are left over from making the testcase I added in this PR. weird that you don't get the same results though 🤔

[asottile]

oh to be clear the code doesn't produce an error -- I'm specifically talking about dmypy suggest

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅