On Tue, 30 Jun 2020 at 11:57, Guido van Rossum email@example.com 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 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/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/