[Python-Dev] Comparison speed (original) (raw)

Guido van Rossum guido@digicool.com
Sun, 20 May 2001 09:56:54 -0400

If the time machine batteries can hold a full charge, you may want to go back and add PyCMP 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 dictrichcompare couldn't compute PyLT/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 tpcompare 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/)