On Wed, 1 Jul 2020 at 03:37, Random832 <random832@fastmail.com> wrote:
On Tue, Jun 30, 2020, at 10:57, Guido van Rossum 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.
> >
> > Anyway, maybe there is a reason it is not a given. Any thoughts?

One thing that may be worth considering is that tuples and lists with the same respective contents are not equal to each other [whereas sets and frozensets are]

I do think it might be worthwhile to have a "compare two sequences" [and possibly also "hash a sequence", to match the tuple hash without making a tuple] building block as a function somewhere, so people could relatively easily make their own [perhaps even something like "__eq__ = collections.sequence_eq"]

Maybe something like collections.mixins.ComparableSequence ? a bundle class with "__eq__", "__ne__", "__le__" -behaving like they do for lists?  

Then, " collections.mixins.HashableSequence"  would also be a natural fit.


If that is interesting enough, maybe more such mixins can be thought of to be added there?
One thing that I've missed sometimes - and is complicated to implement - is to have the 
Sequences generated by collections.abc... to behave properly with slices - 

collections.mixins.SlicedSequence that would override `__delitem__`, `__setitem__` and `__getitem__` and 
handle slices could pair up with the "ComparableSequence"  - people could use these "a la carte", and 
no backwards compatibility would be hurt.



_______________________________________________
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/L2L7FVQFHTMSOU6BE6VGFWKTIORIBPNO/
Code of Conduct: http://python.org/psf/codeofconduct/