False positive: multiple-statements (C0321) should not trigger for stub functions

[GideonBear]

Bug description

For example:

class MyClass(ABC):
    @abstractmethod
    def function(self) -> int: ...  # this should not raise `multiple-statements` error as it's a stub

... is technically a statement, but shouldn't be considered one.

If accepted, I would be interested in submitting a PR for this.

Configuration

No response

Command used

N/A

Pylint output

C0321 More than one statement on a single line (multiple-statements)

Expected behavior

No error

Pylint version

pylint 2.16.0-dev
astroid 2.12.13
Python 3.9.15 (main, Nov 11 2022, 13:33:56) 
[GCC 9.4.0]

OS / Environment

No response

Additional dependencies

No response

[clavedeluna]

I think the warning is correct as is. Same rational for raising the warning on if 1: return True, it's easier to read when ... is in a separate line.

Is there a PEP that says otherwise?

[mbyrnepr2]

Currently, functions decorated with typing.overload are permitted to have it on the same line; so there is precedent in pylint for this proposed change.

[GideonBear]

Is there a PEP that says otherwise?

PEP 8 doesn't say it specifically, but in other recommendations it does put ... on the same line in some examples.

[mbyrnepr2]

Are you importing abstractmethod from abc? I think it works already.

Update: Whoops ignore that 👓

[GideonBear]

Are you importing abstractmethod from abc? I think it works already.

Not working both for @abstractmethod and @property + @abstractmethod

[GideonBear]

It does work for Protocols though.

[mbyrnepr2]

I think its common-enough to have this pattern on the same line; but let's wait a bit for more feedback from maintainers.

[mbyrnepr2]

We could try a vote to make it easier:

🚀 for false-positive (we will remove the message when ellipsis is on the same line)
👀 Do nothing (ellipsis should be on the following line)

[GideonBear]

It should be as easy as replacing this with return

[mbyrnepr2]

I think you are good to go @GideonBear 😀