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

[Noam Raphael]

On 11/6/05, Josiah Carlson <jcarlson at uci.edu> wrote:
...
> >
> > Sorry, I meant complexity to the Python user - it won't require him to
> > learn more in order to write programs in Python.
>
> Ahh, but it does add complexity.  Along with knowing __doc__, __slots__,
> __metaclass__, __init__, __new__, __cmp__, __eq__, ..., __str__,
> __repr__, __getitem__, __setitem__, __delitem__, __getattr__,
> __setattr__, __delattr__, ...
>
>
> The user must also know what __cmp_include__ and __cmp_exclude__ means
> in order to understand code which uses them, and they must understand
> that exclude entries overwrite include entries.
>
You are right. But that's Python - I think that nobody knows all the
exact details of what all these do. You look in the documentation. It
is a compliation - but it's of the type that I can live with, if
there's a reason.
>
> > > 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.
>
> So put it in the Python Cookbook:
> http://aspn.activestate.com/ASPN/Cookbook/Python
>
A good idea.
>
> > > > 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.
>
> You are making a value judgement on what people want to happen with
> default Python. Until others state that they want such an operation as a
> default, I'm going to consider this particular argument relatively
> unfounded.
>
All right. I will try to collect more examples for my proposal.
>
> > > 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.
>
> It won't be OK.  Every comparison using the default operator will incur
> a speed penalty while it checks the (pure Python) warning machinery to
> determine if the warning has been issued yet.  This alone makes the
> transition require a __future__ import.
>
How will the __future__ statement help? I think that the warning is
still needed, so that people using code that may stop working will
know about it. I see that they can add a __future__ import and see if
it still works, but it will catch much fewer problems, because usually
code would be run without the __future__ import.

If it really slows down things, it seems to me that the only solution
is to optimize the warning module...

Noam