> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4