thank you for highlighting this case. currently, no message is raised when the is operator is used to compare two types:

type(a) is type(b)

and imo this seems like an inconsistency as both cases (type() comparisons with == and is) should be semantically equivalent in most practical scenarios.

I like the idea of encouraging is, so I'm actually surprised we don't have some other message for discouraging == here.

Hi,

I'd like to work on fixing this issue. Could you confirm whether the behavior described in the table below reflects the expected behavior? (Perhaps add a new message suggesting the use of 'is' instead of '==').

Thanks for expressing interest, @nedelcu-ioan. A bit of context about this issue, OP is referring to a "strict" type comparison here. In most cases, we want to use the idiomatic way isinstance to perform type checks, which accounts for inheritance. i.e. Given that class C extends class B, isinstance(C(), B) returns True.

But there may be specific cases where we want to perform a "strict" comparison to check if both types are strictly equal, that's when == and is should be used over isinstance.

That's why we should maintain current behavior for all cases except for type(a) == type(b) - which should not raise C0123. @jacobtylerwalls suggests that we should raise a different message (in another check) for type(a) == type(b), because is is safer than == in this scenario, where == behavior can be overridden.

type(a) == type(b)  # do not raise C0123, and perhaps suggest using "is" instead of "==" in another check
type(a) is type(b)  # do not raise C0123 (no change in behavior)
type(a) == int  # raise C0123 (no change in behavior)
type(a) is int  # raise C0123 (no change in behavior)
isinstance(a, type(b))  # do not raise C0123 (no change in behavior)

Agree with @zenlyj's analysis. Sorry if my tangent was distracting. I'd be interested to explore expanding comparison-with-callable to include classes (constructors), not just functions, but we'd need to look at how disruptive that would be and should probably be discussed in a separate issue.