Why did you remove the case of TupleType? A named tuple can appear in Type[].

I think this comment should stay here, since the __init__ signature should be checked for all items in an overload.

This reveal is identical to the previous one. I think you wanted to check something like A[A].

Nah I've probably copied it with the test below somehow :)

Although Type[A] is lower than M, I think this could be allowed. The special-casing probably should be in checkmember.bind_self (then you will also not need special-casing EnumMeta above). My idea is following:

class M(type):
    def g2(cls: Type[TA]) -> TA:
        ...
    def g4(cls: TM) -> None:
        ...
class A(metaclass=M): ...
class A2(A): ...
class B(metaclass=M): ...
A.g2() # OK, inferred type is 'A'
A2.g2() # OK, inferred type is 'A2'
B.g2() # Error, g2 should be only called on subclasses of A
A.g4(), A2.g4(), B.g4() # All are OK

The situation with one "privileged" class with a given metaclass sometimes appears in frameworks. This will allow users to give more precise types in such situation.

So this is probably a more general decision to be made. Instead of requiring a supertype, we can require a related type - either a supertype or a subtype, in which case there's a check at the point of use, just like any other function.

Although I'm not sure why add g2 in M instead of in A as a classmethod

So this is probably a more general decision to be made. Instead of requiring a supertype, we can require a related type - either a supertype or a subtype, in which case there's a check at the point of use, just like any other function.

I would vote for doing this first only for self types in metaclasses (since this is a situation where we know this is needed).

Although I'm not sure why add g2 in M instead of in A as a classmethod

Yes, but this will not work for dunder methods.

I see.
Adding checks at access seems to have non local effect, which makes this PR significantly more complex. Perhaps it will be better to split it up, and add the check at access only later.

It looks here are four examples.

I would add few reveal_types for methods in these tests, just in case.

I tried, although I'm not sure what information is gained.

Actually I wanted something like reveal_type(A.g1) and reveal_type(A.g1()), in particular, where return types of g2 etc. depend on type variables (like List[TA]). Plus also the situations where name of staticmethod/classmethod in class coincides with a name of a method in metaclass.

Actually I wanted something like reveal_type(A.g1) and reveal_type(A.g1()), in particular, where return types of g2 etc. depend on type variables (like List[TA]). Plus also the situations where name of staticmethod/classmethod in class coincides with a name of a method in metaclass.

@elazarg Have you added these tests? Otherwise I think this PR looks good.
@JukkaL could you please try this PR with the Dropbox internal codebase before it is merged?

Hmm I'm pretty sure I did, but probably forgot to push... :\ I will check.

Ok, I don't have time at this moment, so I tried pushing kinda blindly. I might have mixed up something. This supposed to be the tests only, not the check-on-access you've asked for. I hope I did not mess up too bad; if I did, I can probably try to fix it later this week. In such case, it can still be useful to check earlier commit against the internal repo.

Sorry about the mess.

@ilevkivskyi I can try this with Dropbox internal code tomorrow (need to go now).

No worries, I have tried this with our internal code, there are no new errors this found (either in our codebase or in the PR). I haven't reviewed the PR though so I can't "Approve" it. But Ivan can.