Serhiy Storchaka added the comment: > I think it should fall in the same category as Py_RETURN_TRUE or > Py_RETURN_NONE. Sure, it's easy to reimplement, but a lot of extensions > need it; why should everyone need to write the same code in a dozen > different ways? I specifically want this usable in third-party code.
The interface of Py_RETURN_TRUE is simple and unambiguous. Py_RICHCOMPARE is more complex and unobvious. One question is about the order of arguments (opcode as first argument looks better on my taste). Other question is about return value. Should it be an integer 0 or 1, Python object. Stefan ask good question about implementation. A sequence of ifs can be less efficient than one switch. Py_RETURN_TRUE and Py_RETURN_NONE are used hundreds times in CPython code and in any large extension (and can be used more). But the use case of Py_RICHCOMPARE is pretty limited. > The implementation of Py_RICHCOMPARE is in the first patch. Ah, I see the code in text patch, but on Rietveld it isn't visible. Perhaps Rietveld doesn't show some parts from the second patch. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23699> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
