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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com