[issue23699] Add a macro to ease writing rich comparisons

Change by Nick Coghlan : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue23699] Add a macro to ease writing rich comparisons

Nick Coghlan added the comment: New changeset e8b19656396381407ad91473af5da8b0d4346e88 by Nick Coghlan (stratakis) in branch 'master': bpo-23699: Use a macro to reduce boilerplate code in rich comparison functions (GH-793)

[issue23699] Add a macro to ease writing rich comparisons

Benjamin Peterson added the comment: On Tue, Oct 24, 2017, at 02:23, Petr Viktorin wrote: > > Petr Viktorin added the comment: > > Both tp_richcompare and PyObject_RichCompareBool have op as the last > argument: Yes, indeed. Sorry, I wasn't thinking

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Both tp_richcompare and PyObject_RichCompareBool have op as the last argument: https://docs.python.org/3/c-api/object.html#c.PyObject_RichCompareBool

[issue23699] Add a macro to ease writing rich comparisons

Benjamin Peterson added the comment: IMO, "op" should be the first argument to the macro, since that reflects the tp_richcmp API. -- nosy: +benjamin.peterson ___ Python tracker

[issue23699] Add a macro to ease writing rich comparisons

Charalampos Stratakis added the comment: PR has been rebased on top of master and also blurbified. -- ___ Python tracker ___

[issue23699] Add a macro to ease writing rich comparisons

Nick Coghlan added the comment: Assigning to myself to review. To add some context that hasn't come up previously, the essential idea for this macro originated in the "Py3C" extension module compatibility project, where it helps authors of Python 2 extension modules update their projects to

[issue23699] Add a macro to ease writing rich comparisons

Charalampos Stratakis added the comment: Sent a PR against the master branch. What do you think about it? Would it make sense as well for python 3.6 now? -- nosy: +cstratak ___ Python tracker

[issue23699] Add a macro to ease writing rich comparisons

Changes by Charalampos Stratakis : -- pull_requests: +698 ___ Python tracker ___ ___

[issue23699] Add a macro to ease writing rich comparisons

Changes by Ethan Furman et...@stoneleaf.us: -- nosy: -ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699 ___ ___ Python-bugs-list

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Just a reminder: if you want this to be in Python 3.5, please review the patch -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699 ___

[issue23699] Add a macro to ease writing rich comparisons

Stefan Krah added the comment: NotImplemented is a non-error return value that's used when the objects cannot be compared, e.g. when the function receives Py_LT but the objects are unorderable. Getting a value outside {Py_EQ, ...} is a hard error that cannot occur in a correct program.

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Here is a version with PyErr_BadArgument. -- Added file: http://bugs.python.org/file39455/richcompare-macro-badargument.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699

[issue23699] Add a macro to ease writing rich comparisons

Stefan Krah added the comment: It seems that it won't be easy to find an API that pleases everyone. I don't want to prolong the discussion much, but if the macro goes in, returning PyErr_BadArgument() in the default case would be better than NotImplemented. assert(0) would be fine as well.

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Well, in my opinion NotImplemented is a good value for unknown operation, but I'll be happy to change to PyErr_BadArgument(); return NULL; if there's support for that. -- ___ Python tracker rep...@bugs.python.org

[issue23699] Add a macro to ease writing rich comparisons

Stefan Krah added the comment: I mean it's clearer to have: result = long_compare(self, other); return Py_cmp_to_bool(result, op); than: result = long_compare(self, other); Py_RETURN_RICHCOMPARE(result, 0, op); This is because in other places, like the proposed use case in

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Conceptually there's a distinction between the two cases, but you can implement one in terms of the other, so I don't think it's worth adding two functions/macros here. So let's pick the better API. Py_cmp_to_bool is better if you already have a cmp-style

[issue23699] Add a macro to ease writing rich comparisons

Marc-Andre Lemburg added the comment: On 18.05.2015 15:46, Stefan Krah wrote: Stefan Krah added the comment: The problem with this macro is that most of the time it takes the standard cmp return value {-1,0,1} and converts that into a bool. For this use case, it might be more

[issue23699] Add a macro to ease writing rich comparisons

Stefan Krah added the comment: The problem with this macro is that most of the time it takes the standard cmp return value {-1,0,1} and converts that into a bool. For this use case, it might be more appropriate to use a static inline function Py_cmp_to_bool(). To put it differently, the macro

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: What can I, not a core developer, do to resolve this disagreement? Should I submit a PEP? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699 ___

[issue23699] Add a macro to ease writing rich comparisons

Raymond Hettinger added the comment: You don't need a PEP. If Barry and Marc-Andre want this to go forward, I won't hold it back. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699 ___

[issue23699] Add a macro to ease writing rich comparisons

Barry A. Warsaw added the comment: @rhettinger: OTOH, a macro can provide uniformity and correctness. If (as appears evident from the patch) those 10 lines of boilerplate are actually implemented subtly differently each time, bugs can be easily introduced. So a well written and documented

[issue23699] Add a macro to ease writing rich comparisons

Marc-Andre Lemburg added the comment: On 14.05.2015 13:29, Petr Viktorin wrote: Marc-Andre, Barry, you expressed interest in the macro on the mailing list; do you still think it's a good idea? Yes. The fact that the macro can save us more than a hundred lines of code in Python itself is

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Well, as a newcomer, I think the macro makes it easier to both grok what the code does, and is about equally difficult when it comes to checking correctness of the code. But I understand that's a subjective. Marc-Andre, Barry, you expressed interest in the

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: From the discussion on the list: - It needs to be a macro, not function, to support various types (unsigned long long, float; possibly C++ stuff with overriden operators) - Another suggestion to change the order of arguments; I still think being the same as

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Is it really not better to give the operation a name, rather than repeating the same ten lines every time? (Well, not the same -- all the modules code it a bit differently, but with the same meaning.) I might be true that the types in Python itself are done,

[issue23699] Add a macro to ease writing rich comparisons

Raymond Hettinger added the comment: I'm -1 on this whole concept and I don't believe that it will make porting easier. It takes longer to learn the macro, see what it does, write tests for it, etc than it takes to model ten lines of boilerplate code. The macros make it harder for me and

[issue23699] Add a macro to ease writing rich comparisons

Raymond Hettinger added the comment: FWIW, I prefer the current form so that I don't have to constantly lookup to see exactly what the macro does. If this has been around from the beginning, it might have eased the writing by a minute or so. But now, it will just be a barrier to

[issue23699] Add a macro to ease writing rich comparisons

Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699 ___ ___ Python-bugs-list mailing

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: ping Anything I can do to help move this forward? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699 ___ ___

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Changed the macro to Py_RETURN_RICHCOMPARE. This is not an expression, allowing the use of a switch statement. On the other hand, it's even larger macro than before now. From the discussion it seems that doing this correctly is tricky to do this correctly -

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Attaching another patch: - Leave _decimal alone per maintainer's wishes - Fixes issues pointed out in the review - Use Py_RICHCOMPARE also in _tkinter - More improvements in the other affected modules -- Added file:

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Making it a function might help with the following issues: - series of comparisons and PyBool_FromLong is less efficient than switch and Py_RETURN_*. But it would add a function call. - it might be too complex for a macro Do you think that would help? As for

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Serhiy: Thanks for looking at this! 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

[issue23699] Add a macro to ease writing rich comparisons

Serhiy Storchaka added the comment: 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

[issue23699] Add a macro to ease writing rich comparisons

Petr Viktorin added the comment: Here is a patch that uses the macro in all the places it can help. -- Added file: http://bugs.python.org/file38542/0002-Use-Py_RICHCOMPARE-in-rich-comparisons.patch ___ Python tracker rep...@bugs.python.org

[issue23699] Add a macro to ease writing rich comparisons

New submission from Petr Viktorin: Rich comparison functions of many builtin types include a block of boilerplate which can be consolidated in a macro. The macro can be useful for third-party extensions as well as CPython itself. See this e-mail for a longer write-up:

[issue23699] Add a macro to ease writing rich comparisons

Changes by Stefan Krah ste...@bytereef.org: -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699 ___ ___ Python-bugs-list mailing

[issue23699] Add a macro to ease writing rich comparisons

Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699 ___ ___ Python-bugs-list

[issue23699] Add a macro to ease writing rich comparisons

Stefan Krah added the comment: Hmm, at least for the version at https://mail.python.org/pipermail/python-ideas/2015-March/032564.html I'm not sure if the optimizer will produce the same code as for the switch statement. Did you look at the asm? --

[issue23699] Add a macro to ease writing rich comparisons

Serhiy Storchaka added the comment: Such macros would make the code cleaner. But I don't think it should be provided as a part of API. It isn't hard to implement, it doesn't provide essential functionality of Python, and it doesn't hide implementation defined CPython internals. I rather

[issue23699] Add a macro to ease writing rich comparisons

Serhiy Storchaka added the comment: gcc -O3 generates a sequence of cmp-s. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23699 ___ ___