[Python-Dev] Should the default equality operator compare values instead of identities?

[Noam Raphael]

On 11/3/05, Josiah Carlson <jcarlson at uci.edu> wrote:
...
>
> Right, but lists (dicts, tuples, etc.) are defined as containers, and
> their comparison operation is defined on their contents.  Objects are
> not defined as containers in the general case, so defining comparisons
> based on their contents (as opposed to identity) is just one of the two
> assumptions to be made.
>
> I personally like the current behavior, and I see no /compelling/ reason
> to change it.  You obviously feel so compelled for the behavior to
> change that you are willing to express your desires.  How about you do
> something more productive and produce a patch which implements the
> changes you want, verify that it passes tests in the standard library,
> then post it on sourceforge.  If someone is similarly compelled and
> agrees with you (so far I've not seen any public support for your
> proposal by any of the core developers), the discussion will restart,
> and it will be decided (not by you or I).

Thanks for the advice - I will try to do as you suggest.
>
>
> > To summarize, I think that value-based equality testing would usually
> > be what you want, and currently implementing it is a bit of a pain.
>
> Actually, implementing value-based equality testing, when you have a
> finite set of values you want to test, is quite easy.
>
> def __eq__(self, other):
>     for i in self.__cmp_eq__:
>         if getattr(self, i) != getattr(other, i):
>             return False
>     return True
>
> With a simple metaclass that discovers all of those values automatically,
> and/or your own protocol for exclusion, and you are done.  Remember, not
> all 5-line functions should become builtin/default behavior, and this
> implementation shows that it is not a significant burdon for you (or
> anyone else) to implement this in your own custom library.
>
You are right that not all 5-line functions should become
builtin/default behaviour. However, I personally think that this one
should, since:
1. It doesn't add complexity, or a new builtin.
2. Those five line doesn't include the metaclass code, which will
probably take more than five lines and won't be trivial.
3. It will make other objects behave better, not only mine - other
classes will get a meaningful comparison operator, for free.
>
> P.S. One thing that you should remember is that even if your patch is
> accepted, and even if this is desireable, Python 2.5 is supposed to be
> released sometime next year (spring/summer?), and because it is a
> backwards incompatible change, would need at least 2.6-2.7 before it
> becomes the default behavior without a __future__ import, which is
> another 3-4 years down the line.

I hope that the warning can go in by Python 2.5, so the change (which
I think will cause relatively few backwards incompatibility problems)
can go in by Python 2.6, which I think is less than 2 years down the
line.
>
> I understand you are passionate, really I do (you should see some of my
> proposals), but by the time these things get around to getting into
> mainline Python, there are high odds that you probably won't care about
> them much anymore (I've come to feel that way myself about many of my
> proposals), and I think it is a good idea to attempt to balance - when
> it comes to Python - "Now is better than never." and "Although never is
> often better than *right* now."
>
> Removing __hash__, changing __eq__, and trying to get in copy-on-write
> freezing (which is really copy-and-cache freezing), all read to me like
> "We gotta do this now!", which certainly isn't helping the proposal.
>
Thanks - I should really calm down a bit. I will try to go "safe and
slowly", and I hope that at the end I will succeed in making my own
small contribution to Python.

Noam