Inconsistency between ``is``/``is not`` and ``==``/``!=`` when comparing types for ``unidiomatic-typecheck``

[dgutson]

Bug description

I think that pylint should detect the case when type() is used to compare two types, in which case IMHO isisntance() should not be used:

if type(a) == type(b):
    ...

Configuration

Command used

pylint

Pylint output

C0123: Use isinstance() rather than type() for a typecheck. (unidiomatic-typecheck)

Expected behavior

No error triggered.

Pylint version

pylint 3.0.3
astroid 3.0.2
Python 3.12.3 (main, Nov  6 2024, 18:32:19) [GCC 13.2.0]

OS / Environment

No response

Additional dependencies

[zenlyj]

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.

[jacobtylerwalls]

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

[nedelcu-ioan]

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 '==').

Code Example	Current Behavior	Proposed Behavior
type(a) == type(b):	C0123 raised	Detect and suggest using is instead of ==.
type(a) is type(b):	C0123 raised	No message.
type(a) == int:	C0123 raised	Detect and suggest using is instead of ==.
type(a) is int:	C0123 raised	No message.
isinstance(a, type(b)):	No message	No message (no change).

[zenlyj]

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)

[jacobtylerwalls]

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.