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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4