Bug Report

(To be fair, this might be a slight quirk in PEP 673 rather than a bug mypy's implementation).

Certain dunderscored methods are implicitly static, such as __new__. Personally, I prefer to be explicit and so I would like to decorate such methods with @staticmethod explicitly even though, of course, it isn't strictly required. However, I just ran into a case where mypy treats my __new__ method differently if I add the decorator.

In particular, I was playing around with the new(ish) typing.Self feature. The PEP says, under "valid locations for Self":

def __new__(cls, value: int) -> Self: ...  # Accepted

Which is slightly confusing since it also says, a bit further down.

Note that we reject Self in staticmethods

To Reproduce

class Implicit:

    #@staticmethod
    def __new__(cls) -> typing.Self:
        return super().__new__(cls)

class Explicit:

    @staticmethod
    def __new__(cls) -> typing.Self:
        return super().__new__(cls)

Expected Behavior

I would expect mypy to treat Implicit and Explicit the same, whether there is a @staticmethod decoration or not.

Actual Behavior

Mypy flags a bunch of issues with the Explicit class, but not with the Implicit one.

Your Environment

• Mypy version used: mypy 1.2.0 (compiled: yes)
• Mypy command-line flags: n/a
• Mypy configuration options from mypy.ini (and other config files): n/a
• Python version used: Python 3.11.3

Addendum

I was actually attempting to annotate the cls argument to __new__ as being of type typing.Type[typing.Self] but that's not allowed in either the implicit or the explicit cases, but that makes sense now that I think about it.