On Tue, 30 Jun 2020 at 11:57, Guido van Rossum <guido@python.org> wrote:
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)):
            return False

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__")


On Tue, Jun 30, 2020 at 5:16 AM Joao S. O. Bueno <jsbueno@python.org.br> wrote:
Is there any reason why collections.abc.[Sequence|MutableSequence] do
not have "__eq__" for free?

I was writing some tests now and was caught by surprise there.

(chcking the docs, if my custom MutbaleSequence also
inherits from "collections.abc.Set" I will have working "__eq__" - and "__ne__", methods
but also weirdly behaved "__le__" and cousins as a side efffect  - weird enough
I think i will just hand-write the "__eq__")

While theoretically adding "__eq__"  and "__ne__" _could_ hab
backward compatibility issues, I think it is more probable it would
actually fix some undetected bugs i a couple projets, as the default __eq__ is
an identity comparison (is). 

Anyway, maybe there is a reason it is not a given. Any thoughts?

Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BZTYVERLYDWPMW2QKSMDWXRRL3DUBSDC/
Code of Conduct: http://python.org/psf/codeofconduct/

--Guido van Rossum (python.org/~guido)