Infer the 'cls' argument of a classmethod as the defining class, not Any

[JukkaL]

Add support for classmethod. Currently we support staticmethod.

[JukkaL]

Partial support implemented in db9efde by Jeff Walden.

[mrwright]

For reference, here's an example of code that incorrectly typechecks because of this:

class C(object):
    @classmethod
    def f(cls, a, b):
        # type: (int, int) -> None
        pass

    @classmethod
    def g(cls):
        # type: () -> None
        cls.f(2, 3, 4)

Replacing cls.f with C.f correctly produces a Too many arguments for "f" of "C" error. This situation came up in code I was annotating.

[JukkaL]

The type of cls in currently implicitly Any, which is way too general. The reason why this hasn't been implemented yet is that the type of cls is actually quite subtle with respect to __init__.

Consider this example:

class A:
    def __init__(self, x: int) -> None: ...

    @classmethod
    def f(cls) -> None:
        a = cls(1)
        ...

class B(A):
    def __init__(self, x: int, y: str) -> None: ...

B.f()  # runtime error

To catch the above error, we have at least two options:

1. Reject calls to cls. This would be too restrictive but pretty straightforward to implement. Instead of calling cls, you could implement a factory class method and call that, but that would be less convenient.
2. Somehow prevent overriding __init__ with an incompatible signature in some cases such as B above. Usually we should allow these overrides.

We could also decide to not care about this and allow calling cls with arbitrary arguments (type would be something like Callable[..., A]).

For 2, we could provide an annotation that enforces this. Here are some potential ways to do it:

• Class decorator (for A in the above example)
• Method decorator (for A.__init__)
• Magic comment such as # mypy: compatible-init-override within class body or within __init__

The same issue also happens with __new__.

There are other related things around this such as 'self types' but they aren't immediately relevant to this issue.

[gvanrossum]

Could we do this in two stages? In stage 1 we change the type of cls to be A (in general, the class that lexically contains the class method definition). We'd catch calls of cls() with arguments that don't match the lexically current `__init__` or `__new__` (which is Matthew's example). We wouldn't catch the subclass that changes the signature for `__init__` or `__new__` but neither do we catch that today. In stage 2 we add code that restricts the signature of subclass constructors to be compatible with the base class constructor, but only if there are any calls to cls() in the base class. Now, there might be cases where a mix-in class assumes a specific signature for cls() that isn't obvious from the mix-in class's own definition, but mix-in classes are already wildly problematic. A systematic approach to mix-in classes requires the code to be refactored to use ABCs that declare the interface assumed by the mix-in class.

[JukkaL]

Sounds pretty reasonable. We figure out the details of stage 2 later on; stage 1 is simple to implement.

[JukkaL]

Looking for cls() is not good enough for stubs, as they have empty method bodies. We could use an __init__ decorator to mark that subclasses should use a compatible signature.

[gvanrossum]

Honestly I've always found cls() of dubious correctness -- similar to self.__class__(). But yes, people do use it. :-(

[gnprice]

For the thread: we've heard this request several times now at Dropbox, where we have a lot of classmethods. One place we heard it was on our recent survey of internal users.