Pylint is not smart enough when analyzes functions returning coroutine.

[socketpair]

Bug description

from asyncio import sleep
from typing import Any, Awaitable, Coroutine


class A:
    async def fun(self) -> None:
        pass


class B(A):
    def fun(self) -> Awaitable[None]:
        return sleep(42)


class C(A):
    def fun(self) -> Coroutine[Any, Any, None]:
        return sleep(42)

Configuration

No response

Command used

pylint a.py

Pylint output

W0236: Method 'fun' was expected to be 'async', found it instead as 'non-async' (invalid-overridden-method)

Expected behavior

no warnings/errors

Pylint version

pylint 3.0.4
astroid 3.0.3
Python 3.12.3 (main, Apr 17 2024, 00:00:00) [GCC 13.2.1 20240316 (Red Hat 13.2.1-7)]

OS / Environment

Fedora 39

Additional dependencies

No response

[DanielNoord]

I would argue that this is expected behaviour? We don't look at type annotations so I don't see how we could reliably do this without looking at whether async is missing. I also think this is a weird pattern you're introducing for which it is fine to have a somewhat opinionated linter check?

[socketpair]

It is used in existing code, and it is faster than

async def fun():
    return await another_fun()

[DanielNoord]

Why is it faster? I have never heard about this, but if it is indeed we should turn this pattern itself into a recommendation?

[socketpair]

@DanielNoord

from asyncio import run
from time import monotonic
from typing import Any, Coroutine


async def something() -> None:
    return


async def slow_fun() -> None:
    return await something()


def fast_fun() -> Coroutine[Any, Any, None]:
    return something()


async def test_slow() -> None:
    for i in range(1000_000):
        await slow_fun()


async def test_fast() -> None:
    for i in range(1000_000):
        await fast_fun()


run(something())  # warm-up

a = monotonic()
run(test_fast())
b = monotonic()
print('fast', b - a)

a = monotonic()
run(test_slow())
b = monotonic()
print('slow', b - a)

fast 0.0913987820094917
slow 0.12168889299209695

1. it IS faster by benchamarks, not only in theory.
2. I don't think it should be recommendation. But it is not a mistake to have such kind of code.

[DanielNoord]

Hmm that is interesting, I didn't know. I guess you're running into the overhead of asyncio itself here.

I guess we should indeed disable the warning in this case, although it still feels like a bit of an anti-pattern.