RetroSearch Browse

Fri Mar 19 01:21:09 EST 2004 · https://mail.python.org/pipermail/python-dev/2004-March/043279.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-March/043279.html below:

[Python-Dev] Rich comparisons [Was] redefining is