False positive: Condition will always evaluate to False since the types "bytearray" and "bytes" have no overlap

[max-kamps]

Playground link

data1 = bytearray(4)
data2 = bytes(4)

if data1 == data2:
    print("Four zeros are four zeros!")

Results in the warning Condition will always evaluate to False since the types "bytearray" and "bytes" have no overlap.

But this is incorrect, comparing bytearray and bytes with == returns True if they have the same content.

A related issue occurs with literals:

data = bytearray(4)
value = b"\0\0\0\0"

if data == value:
    print("Four zeros are four zeros!")

Results in the warning Condition will always evaluate to False since the types "bytearray" and "Literal[b"\x00\x00\x00\x00"]" have no overlap.

[behlole]

Tracked this down to isTypeComparable in packages/pyright-internal/src/analyzer/typeEvaluator.ts (~L26097).

The check has an early "disjoint built-in classes → not comparable" return, with an existing special case for bool / int literals. bytes and bytearray fall into the disjoint-built-in branch because neither subclasses the other, even though CPython's bytes.__eq__ and bytearray.__eq__ cross-compare by content (bytearray(b"a") == b"a" is True at runtime).

The literal form in the issue (bytearray == Literal[b"..."]) hits the same branch because the literal is still a bytes instance.

Proposed fix

Add a bytes / bytearray special case parallel to the existing bool / int one — if both sides are bytes-like built-ins, treat as comparable. Plus a new comparison3.py sample with:

• bytes ↔ bytearray (both directions, == and !=) — must NOT emit reportUnnecessaryComparison.
• bytearray ↔ Literal[bytes] — must NOT emit.
• bytes ↔ str regression — must still emit.

Total: ~28 lines added across typeEvaluator.ts, comparison3.py, and typeEvaluator6.test.ts. No behavior change for non-bytes-like comparisons.

Happy to open a PR — fix is drafted and tests follow the existing comparison1/2.py sample-based pattern.