https://github.com/astral-sh/ruff/pull/13903/files#diff-eff9f162b9d83ddfe43d3f6b28ed022767bc58d12d7ccb0c95d985e827471362R91-R95

It seems that inferring Literal types based on only rich comparison and typeshed may not be feasible.

The __eq__ method in both builtin.str and builtin.int has an argument type of object.

https://github.com/astral-sh/ruff/blob/main/crates/red_knot_vendored/vendor/typeshed/stdlib/builtins.pyi#L590
https://github.com/astral-sh/ruff/blob/main/crates/red_knot_vendored/vendor/typeshed/stdlib/builtins.pyi#L319

The __eq__ method in both builtin.str and builtin.int has an argument type of object.

Right. The convention when it comes to annotating parameters on __eq__ and __ne__ is different from the other four rich-comparison methods. As far as I'm aware, this is unspecified.

The convention for nearly all rich-comparison and binary-arithmetic dunders is to annotate them in such a way that any call that would result in NotImplemented being returned would lead to the type checker emitting an error. So although this "works" at runtime (no error is raised, just NotImplemented returned), typeshed's annotations disallow it:

>>> (2).__lt__(2.0)
NotImplemented

But for __eq__ and __ne__, the convention is to annotate parameters such that any calls that would succeed at runtime are allowed, even if those successful calls would return NotImplemented. I can think of two good reasons for this:

1. __eq__ and __ne__ really are different from all the others: unlike the other rich-comparison operators and the binary-arithmetic operators, x == y will always result in a bool (never TypeError), even if type(x).__eq__(y) returns NotImplemented and type(y).__eq__(x) returns NotImplemented.
2. It's useful for type checkers to enforce the Liskov Substitution Principle for equality. If a class raises an exception during an equality check, that seriously violates some assumptions that are baked in across the language, standard library, and many third-party libraries. It's useful to be able to distinguish "this __eq__ method returns NotImplemented if you pass it a float" and "this __eq__ method raises TypeError or AttributeError if you pass it a float", because the first is fine but the second is very bad indeed. With the current convention, type checkers will warn you if you say that an __eq__ method has to accept a non-object type, because that's an incompatible override of object.__eq__ (they're able to detect the Liskov violation).

In this particular case, I think we should be able to infer Literal False and True, without ever falling back to typeshed, because we should explicitly implement equality comparison for mismatched Literal types to return Literal[False]. (Currently we just don't have a match arm for that case, so we fall back to the typeshed definitions instead.)

Yes, just because we should emit a diagnostic telling the user off doesn't mean we should ignore what the annotation says! So this looks correct to me.