Message238674
> 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. |
|
Date |
User |
Action |
Args |
2015-03-20 13:56:02 | serhiy.storchaka | set | recipients:
+ serhiy.storchaka, petr.viktorin, skrah, ethan.furman |
2015-03-20 13:56:02 | serhiy.storchaka | link | issue23699 messages |
2015-03-20 13:56:01 | serhiy.storchaka | create | |
|