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

[Noam Raphael]

On 11/5/05, Josiah Carlson <jcarlson at uci.edu> wrote:
...
> > 1. It doesn't add complexity, or a new builtin.
>
> It changes default behavior (which I specified as a portion of my
> statement, which you quote.
>
> And you are wrong, it adds complexity to the implementation of both
> class instantiation and the default comparison mechanism.  The former, I
> believe, you will find more difficult to patch than the comparison,
> though if you have not yet had adventures in that which is writing C
> extension modules, modifying the default class instantiation may be
> the deal breaker for you (I personally would have no idea where to start).

Sorry, I meant complexity to the Python user - it won't require him to
learn more in order to write programs in Python.
>
> class eqMetaclass(type):
>     def __new__(cls, name, bases, dct):
>         if '__cmp_include__' in dct:
>             include = dict.fromkeys(dct['__cmp_include__'])
>         else:
>             include = dict.fromkeys(dct.keys)
>
>         for i in dct.get('__cmp_exclude__'):
>             _ = include.pop(i, None)
>
>         dct['__cmp_eq__'] = include.keys()
>         return type.__new__(cls, name, bases, dct)
>
> It took 10 lines of code, and was trivial (except for not-included
> multi-metaclass support code, which is being discussed in another thread).
>
> Oh, I suppose I should modify that __eq__ definition to be smarter about
> comparison...
>
> def __eq__(self, other):
>     if not hasattr(other, '__cmp_eq__'):
>         return False
>     if dict.fromkeys(self.__cmp_eq__) != \
>        dict.fromkeys(other.__cmp_eq__):
>         return False
>     for i in self.__cmp_eq__:
>         if getattr(self, i) != getattr(other, i):
>             return False
>     return True

Thanks for the implementation. It would be very useful in order to
explain my suggestion.

It's nice that it compares only attributes, not types. It makes it
possible for two people to write classes that can be equal to one
another.

>
> Wow, 20 lines of support code, how could one ever expect users to write
> that? ;)

This might mean that implementing it in C, once I find the right
place, won't be too difficult.

And I think that for most users it will be harder than it was for you,
and there are some subtleties in those lines.
>
>
> > 3. It will make other objects behave better, not only mine - other
> > classes will get a meaningful comparison operator, for free.
>
> You are that the comparison previously wasn't "meaningful".  It has a
> meaning, though it may not be exactly what you wanted it to be, which is
> why Python allows users to define __eq__ operators to be exactly what
> they want, and which is why I don't find your uses compelling.
>
I think that value-based equality testing is a better default, since
in more cases it does what you want it to, and since in those cases
they won't have to write those 20 lines, or download them from
somewhere.
>
...
>
> From what I have previously learned from others in python-dev, the
> warnings machinery is slow, so one is to be wary of using warnings
> unless absolutely necessary. Regardless of it being absolutely necessary,
> it would be 2 years at least before the feature would actually make it
> into Python and become default behavior, IF it were desireable default
> behavior.

All right. I hope that those warnings will be ok - it's yet to be
seen. And about those 2 years - better later than never.
...
>
> You should also realize that you can make contributions to Python
> without changing the language or the implementation of the langauge.
> Read and review patches, help with bug reports, hang out on python-list
> and attempt to help the hundreds (if not thousands) of users who are
> asking for help, try to help new users in python-tutor, etc.

I confess that I don't do these a lot. I can say that I from time to
time teach beginners Python, and that where I work I help a lot of
other people with Python.

> If you
> have an idea for a language change, offer it up on python-list first
> (I've forgotten to do this more often than I would like to admit), and
> if it generally has more "cool" than "ick", then bring it back here.
>
I will. Thanks again.

Noam