This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serhiy.storchaka
Recipients ethan.furman, petr.viktorin, serhiy.storchaka, skrah
Date 2015-03-20.13:56:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <7358191.Rcgm0z3cSD@raxxla>
In-reply-to <1426855410.95.0.297635930032.issue23699@psf.upfronthosting.co.za>
Content
> 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.
History
Date User Action Args
2015-03-20 13:56:02serhiy.storchakasetrecipients: + serhiy.storchaka, petr.viktorin, skrah, ethan.furman
2015-03-20 13:56:02serhiy.storchakalinkissue23699 messages
2015-03-20 13:56:01serhiy.storchakacreate