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

using this sample code:

from __future__importannotationsfromtypingimportCallable,Protocol,TypeVar,Anyfromtyping_extensionsimportParamSpec,TypeAliasdefdec(f:Callable[...,Any])->Callable[...,Any]:returnf@decdeff(x,y):returnx+yf(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 outone of the parameters but not both and then not the return value 🤔)

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.

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 🤔

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

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

Hm, this seems to be the reason whydmypy suggest didn't allow decorators that don't preserve signature explicitly. In your example the argument types for the call site are not mapped correctly: the first argument isLiteral[1] | Literal[2] and the second argument has no type information at all, as if the signature wasdef fn(*args) - consistent withCallable[..., T] interpretation asdef (*args: Any, **kwargs: Any) -> T. This mapping comes from straight fromFunctionContext, so that's a limitation of howmypy treats calls ofCallable[..., T] internally.

Dumping the call sites, we have this single entry there:

Callsite(    path='b.py',     line=12,     arg_kinds=[[<ArgKind.ARG_POS: 0>, <ArgKind.ARG_POS: 0>], []],     callee_arg_names=[None, None],     arg_names=[[None, None], []],     arg_types=[[Literal[1]?, Literal[2]?], []])

Where i-th element of a 2D list contains types mapped to i-th formal argument of the function.f at that moment isdef (*Any, **Any) for the type checker but(x: Any, y: Any) for the suggestion engine, and this discrepancy manifests in quite weird results. It's possible to update your example to make it exhibit even weirder behavior - if you dof(1, ''), for example, the inferred signature would be(x: object, y: Any) -> Any. And this will crash altogether with anIndexError:

from __future__importannotationsfromtypingimportCallable,Anydefdec(f:Callable[...,Any])->Callable[...,Any]:returnf@decdeff(x,y,z):returnx+yf('',0,1)

It might be better to disallow such decorators again and revert/update#19072... But this change (usingis_same_type) is certainly good on its own.