[Python-Dev] Comparison speed

[Guido van Rossum]

> If the time machine batteries can hold a full charge, you may want to go back
> and add Py_CMP as a seventh possible desired-operation argument to tbe rich
> comparison API.

Funny, I was thinking about this too last night.

> My experience with dict comparisons was that dict_richcompare
> couldn't compute Py_LT/LE/GT/GE any cheaper than by doing a full
> cmp, so I put the dict oldcmp back in order to avoid having dict
> richcmp (potentially) compute cmp 3 times to fake one cmp.  But if
> dict richcmp knew a cmp outcome was desired, it could compute it
> with no extra work to speak of.  Then there would be no reason at
> all to hold on to the dict tp_compare slot.

I'm not sure I see the saving.  There's no real saving in time,
because you still have to make separate calls for EQ and CMP, right?

There might be a saving in code, but you could solve that internally
in dictobject.c by restructuring the code somewhat so that
dict_compare shared more with dict_richcompare, right?

It's mostly an API streamlining.  The other difference between
tp_compare and tp_richcompare is that the latter returns an object
which makes testing for errors unambiguous.

But (for several releases) we would still have to support tp_compare
for b/w compatibility with old 3r party extensions.

> The list and tuple richcmps are also doing almost all the work needed to
> compute a 3-way cmp outcome.

Ditto.

--Guido van Rossum (home page: http://www.python.org/~guido/)