I don't recall why this was done. It seems somewhat odd, since Set and Mapping in the same module do have __eq__. I don't care much for the default implementation though.
(I don't understand why you would want to inherit from both Sequence and Set -- and certainly the resulting mongrel type would have to behave weirdly in order to conform to user expectations for both of its parents, regardless of what you do for __le__.)
The idea of inheriting from Seuqence and Set is that, since `Sequence` gives me __iter__, it has the complete
requisites for `set` and then I get the `__eq__` for "free" . On a second thought, it is likely the `Set.__eq__` do not
care about order - I was making some interactive experimentation and did not check that: I stopped when
I found out the __le__ (and related) methods created this way made no sense at all, exactly as you put it.
I ended up writting an __eq__ - and in the process I found it is not _that_ straightforward due
to having to check subclasses types when comparing.
(given Base sequence A, child class B(A), class C(A) and class B1(B) - Instances of B and B1 can be
equal, but instances of B and C should always be different) - or in Python, inside __eq__ :
if not issubclass(type(other), type(self)) and not issubclass(type(self), type(other)):
Traditionally we've been very reluctant to add new methods to existing ABCs, because of the implications for classes everywhere that inherit from these.
yes - I can see that. That is why, even though I am writing this message it is more in a
question tone, than the usual "I want this feature" normally used in this list.
On the other hand I can see no reason why these comparisons are not there, and
can't think of many ways code would break if they were introduced (such code
would have to be relying on the default "is" operation of the default "object.__eq__")