Add support for PEP 698 - override decorator

[tmke8]

closes #14072

This implements support for PEP 698, which has recently been accepted for Python 3.12. However, this doesn't yet add the "strict mode" that is recommended in the PEP.

[tmke8]

I wasn't sure whether to allow it on __init__.

[JelleZijlstra]

Doesn't seem very useful, but I also don't see a reason to explicitly disallow it. @stroxler any thoughts?

[JelleZijlstra]

Thanks! I'll take a look soon. FYI to @stroxler.

[JelleZijlstra]

Doesn't seem very useful, but I also don't see a reason to explicitly disallow it. @stroxler any thoughts?

[stroxler]

I believe the Pyre implementation would allow it, and certainly the rules for the PEP do.

Agreed that it probably isn't very useful - if object has an __init__ then it's not possible for the check to fail.

[tmke8]

Another thing that could be done here is making the compatibility check stricter when @override is used. As issue #1013 notes, mypy is quite lenient when it comes to function parameter names and allows this:

class A:
    def f(self, x: int) -> str: ...
class B(A):
    def f(self, xx: int) -> str: ...

even though B().f(x=2) will not work at runtime.

[tmke8]

@stroxler what about @overloads? The PEP doesn't mention them, but it seems pyright at least supports the following:

from abc import abstractmethod
from typing import overload
from typing_extensions import override

class A:
    @abstractmethod
    def f(self, x: int) -> str: ...

class B(A):
    @overload
    def f2(self, x: int) -> str: ...
    @overload
    def f2(self, x: str) -> str: ...
    @override
    def f2(self, x: int | str) -> str:  #  error: Method "f2" is marked as override, but no base method of same name is present (reportGeneralTypeIssues)
        return str(x)

class C(A):
    @overload
    def f(self, y: int) -> str: ...
    @overload
    def f(self, y: str) -> str: ...
    @override
    def f(self, y: int | str) -> str:  # error: Method "f" overrides class "A" in an incompatible manner
                                       # No overload signature in override is compatible with base method (reportIncompatibleMethodOverride)
        return str(y)

but I don't see an error in the Pyre playground.

[JukkaL]

I couldn't see a test case that uses overloaded methods (using the @overload decorator). Can you test overriding when it involves overloaded methods as well?

[tmke8]

I added the test and also added support for overloads decorated with @override. The rule is now that if any overload item has the decorator, the whole overload is treated as an explicit override.

[tmke8]

The current implementation allows that multiple overload items are decorated with @override. I can also disallow this if desired.

[tmke8]

I could also restrict it to only the first and the last, or something like that.

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

graphql-core (https://github.com/graphql-python/graphql-core) got 1.05x slower (283.0s -> 298.1s)

[hauntsaninja]

This looks good to me, thank you for implementing this!