[Python-Dev] A macro for easier rich comparisons

Glenn Linderman v+python at g.nevcal.com
Tue Apr 28 19:50:22 CEST 2015


On 4/28/2015 2:13 AM, Victor Stinner wrote:
>> #define Py_RETURN_RICHCOMPARE(val1, val2, op)                               \
>> >     do {                                                                    \
>> >         switch (op) {                                                       \
>> >         case Py_EQ: if ((val1) == (val2)) Py_RETURN_TRUE; Py_RETURN_FALSE;  \
>> >         case Py_NE: if ((val1) != (val2)) Py_RETURN_TRUE; Py_RETURN_FALSE;  \
>> >         case Py_LT: if ((val1) < (val2)) Py_RETURN_TRUE; Py_RETURN_FALSE;   \
>> >         case Py_GT: if ((val1) > (val2)) Py_RETURN_TRUE; Py_RETURN_FALSE;   \
>> >         case Py_LE: if ((val1) <= (val2)) Py_RETURN_TRUE; Py_RETURN_FALSE;  \
>> >         case Py_GE: if ((val1) >= (val2)) Py_RETURN_TRUE; Py_RETURN_FALSE;  \
>> >         }                                                                   \
>> >         Py_RETURN_NOTIMPLEMENTED;                                           \
>> >     } while (0)
> I would prefer a function for that:
>
> PyObject *Py_RichCompare(long val1, long2, int op);
Why would you prefer a function?  As a macro, when the op is a constant, 
most of the code would be optimized away by a decent compiler.

I suppose when the op is not a constant, then a function would save code 
space.

So I suppose it depends on the predominant use cases.

> You should also handle invalid operator. PyUnicode_RichCompare() calls
> PyErr_BadArgument() in this case.
One can quibble over the correct error return, but the above code does 
handle invalid operators after the switch.

Glenn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150428/b5ff10f7/attachment.html>


More information about the Python-Dev mailing list