stubtest: relax async checking for abstract methods

[AlexWaygood]

Description

As has been pointed out in python/typeshed#7475, the current typeshed definitions for various async methods in the stub for typing are problematic.

Until recently, these were all "synchronous" methods that returned Awaitable[X]. However, they were recently changed to be async def methods. This more closely match their definitions at runtime, but is problematic: the classes in typing.pyi represent abstract interfaces, and it's not true that an object has to return a coroutine from its __anext__ method in order to be considered an AyncIterator (it just has to return something that's awaitable).

Unfortunately, following #12212, stubtest will now emit an error if a method is async at runtime but not in the stub.

I think it makes sense to relax this check for abstract methods, so that's what this PR proposes doing.

Test Plan

Three new test cases added to teststubtest.py.

cc. @hauntsaninja, @graingert

[AlexWaygood]

Is there a more idiomatic way of figuring out whether the return type of a method in the stub is a subtype of Awaitable[Any]?

[jhance]

I think the unused awaitable stuff does something similar.

[AlexWaygood]

Thanks! I've modified my PR to add a helper property in mypy.types to avoid code duplication

[hauntsaninja]

I'm not sure I fully understand this change, but I'm not yet convinced it's better than an allowlist entry. This seems to encourage LSP violations (nitpicky ones, but still — we seem to be trying to tighten up "returns coroutine" vs "returns awaitable" and this muddies the water). Note also that abstractmethods in Python can have implementations, so the use of an async def in an abstractmethod might have runtime meaning.

[AlexWaygood]

I'm not sure I fully understand this change, but I'm not yet convinced it's better than an allowlist entry.

I see it as similar to the various synchronous abstract methods where we have a looser signature in the stub than the default implementation at runtime.

For example, collections.abc.Iterator.__iter__ and contextlib.AbstractContextManager.__enter__ both return self at runtime. But we wouldn't want them to be annotated with -> Self in the stubs, because these classes are abstract interfaces that represent formal definitions of what it means to be an "iterator" or a "context manager", and a class doesn't have to return self from its __iter__ method order for it to be considered an "iterator".

In the same way, AsyncIterator.__anext__ is a coroutine function at runtime -- that's the default implementation. But a class's __anext__ method doesn't have to be a coroutine function in order for it to be considered an "asynchronous iterator" (though it does need to return an awaitable). So it makes sense to have a looser signature for AsyncIterator.__anext__ than the default implementation, just like it does for collections.abc.Iterator.__iter__ and contextlib.AbstractContextManager.__enter__.

It seems to me that classes with abstract methods are generally going to represent abstract interfaces of some kind. As such, it might often be the case that the default implementation of an abstract method is a coroutine function, even if subclasses are not necessarily expected to implement the method as a coroutine function in order to be considered compatible with the interface. Hence, this PR :)

[AlexWaygood]

If you're still not convinced, feel free to close this, no hard feelings :)

[github-actions]

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

[JelleZijlstra]

Why do we want to allow this? Doesn't seem particularly useful.

[AlexWaygood]

I can't remember, and I'm not sure I care anymore. I guess I'll just close this PR :)