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