David Salvisberg

It's worth noting that the ambiguity only exists in pyi files (and in a regular file with a `from __future__ import annotations` import), since in either case the declarations are...

I think the conclusion we reached in previous attempts was that `ParamSpec` is unsufficient to solve this, due to the complex interaction with `classmethod`. I think the best bet for...

@Aran-Fey `Callable` is special cased inside a class, so `foo: Callable[[int], None]` behaves (almost) the same as if you had written `def foo(self, x: int, /) -> None: ...` The...

While this fixes the incorrect signature, you lose the extra attributes that `functools.cache` introduces this way, so it's at best trading one problem for another. But it can be a...

I assumed this would fall under no type reassignments, but it looks like there's special casing to make this equivalent to decorating the function, but it also looks like your...

> I strongly agree with @Aran-Fey that until this is solved, it would be _much_ better to preserve the function signature at the cost of not checking that parameters are...

You could also try to do what I did to get stubtest running in uWSGI, so there's already a special case here: https://github.com/python/typeshed/blob/6fcd37456d37fddeeb5b0dc091409fc85bb6b1ce/tests/stubtest_third_party.py#L110-L113 This looks actually more simple than the...

Quite a few mypy primer hits here. This change probably does not make sense until after PEP696 support.

This is really encouraging, PEP-696 truly shines here. I'll check if there are any other places in typeshed that use `AbstractContextManager`/`AbstractAsyncContextManager` that should have their second parameter specified. --- I...

One of the mypy_primer hits is irrelevant, since it is the same unrelated error with different types and the other one looks like an improvement to me. There are a...