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

Traditionally we've been very reluctant to add new methods to existing ABCs, because of the implications for classes everywhere that inherit from these.

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
https://mail.python.org/mailman3/lists/python-ideas.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)
Pronouns: he/him (why is my pronoun here?)