Better story around class methods, self types and type object types

[JukkaL]

There are several issues that are pretty closely related to each other. This issue tracks them together. Here are the issues:

• Infer the 'cls' argument of a classmethod as the defining class, not Any #292 (type checking cls argument of class methods) (EDIT: done)
• SelfType or another way to spell "type of self" (or, How to define a copy() function) #1212 (SelfType, return type of a copy() method)
• self.__class__() not supported #1195 (type of self.__class__)
• Can we have a generic Type[C]? typing#107 (Type[T])

Summary of how the above are related:

• If we support Type[T] we could use that as the type of the cls argument in class methods.
• The result of cls(...) could have type SelfType.
• The type of self.__class__ could be Type[T] (similarly for type(self)).

Another thing to discuss is determining/specifying when overrides of __init__ should be compatible with a base class, which is usually not required. For example, we want to restrict __init__ to accept a single argument here:

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

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

class B(A):
    def __init__(self) -> None: ...   # should be rejected!

There are at least are a few different ways of fixing the above issue:

• Detect any calls to cls and if such things exist, enforce __init__ compatibility implicitly. This wouldn't work well in a stub as function bodies are empty.
• Require a magic __init__ decorator or class decorator that causes __init__ compatibility to be enforced. Don't support cls(...) unless the decorator exists.

[JukkaL]

I propose moving this to 0.3.3.

[gvanrossum]

Moved to 0.3.3.

[gvanrossum]

Anything needing a PEP change probably shouldn't be labeled 0.4.x.

Really, the individual issues should be given proper milestones.

[gvanrossum]

Closing, as only #1212 is still open.