RetroSearch Browse

Fri Mar 19 07:01:31 EST 2004 · http://mail.python.org/pipermail/python-dev/2004-March/043281.html

"Raymond Hettinger" <python at rcn.com> writes:

>> [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().

How much is 'so much'?  When I recently implemented rich comparisons
for floats, there was no change in performance that I could discern
(apart from comparing floats to integers which sped up by ~30%).

> Fixing this would entail a change in semantics but would be worth it if
> we can all agree to it.

Bzzt!, then:

>>> float('nan')
nan
>>> _ == _
False

while this is well into the realm of 'platform specific accidents', it
is somewhat desirable.  And will happen in 2.4 on linux, OS X and
Windows as things currently stand (so at a guess 90%+ of Python
installs).

[...]

> I think the change is worth it -- tests for equality are ubiquitous
> (and somewhat common) throughout the source.

But how often are they between identical objects?

Cheers,
mwh

-- 
  If I had wanted your website to make noise I would have licked
  my finger and rubbed it across the monitor.
                           -- signature of "istartedi" on slashdot.org

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

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

[Python-Dev] Rich comparisons