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 firstname.lastname@example.org 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 -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/BZTYVE... Code of Conduct: http://python.org/psf/codeofconduct/