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

Josiah Carlson jcarlson at uci.edu
Sun Nov 6 00:40:34 CET 2005


Noam Raphael <noamraph at gmail.com> wrote:
> 
> 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.

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.


> > 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 


> > > 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.


> > 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.


 - Josiah



More information about the Python-Dev mailing list