[Python-Dev] Rich comparisons [Was] redefining is
Raymond Hettinger
python at rcn.com
Fri Mar 19 01:21:09 EST 2004
> [Guido]
> > (The best scheme is probably to use intern() but still use '==' for
> > comparisons; '==' is smart enough to skip comparing an object to
> > itself.)
[Tim]
> Well, string_richcompare() takes that shortcut, so the advice is good,
but
> PyObject_RichCompare() doesn't in general (PyObject_Compare() still
does,
> but that's not triggered by '==').
Hey, hey, this may be part of the answer to why my timings for equality
testing using rich comparisions run so much slower than they do with
PyObject_Compare().
Fixing this would entail a change in semantics but would be worth it if
we can all agree to it. Essentially, I would like to insert the
following lines into PyObject_RichCompare():
if (v == w) {
if (op == Py_EQ)
Py_RETURN_TRUE;
else if (op == Py_NE)
Py_RETURN_FALSE;
}
The test suite runs fine, but it is possible that some existing class
defines equality in a way that sometimes returns False even when given
two identical objects.
I think the change is worth it -- tests for equality are ubiquitous (and
somewhat common) throughout the source.
Raymond
More information about the Python-Dev
mailing list