[issue10042] total_ordering

Jim Jewett added the comment: I like Nick Coghlan's suggestion in msg140493, but I think he was giving up too soon in the "or" cases, and I think the confusion could be slightly reduced by some re-spellings around return values and comments about short-circuiting. def not_op(op, other):

[issue10042] total_ordering

Changes by Catalin Iacob : -- nosy: +catalin.iacob ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue10042] total_ordering

Nick Coghlan added the comment: Changed stage and resolution to reflect the fact that none of the existing patches adequately address the problem. -- resolution: fixed -> stage: committed/rejected -> needs patch ___ Python tracker

[issue10042] total_ordering

Nick Coghlan added the comment: Also, a note regarding efficiency: as it calls the underlying methods directly and avoids recursing through the full operand coercion machinery, I would actually expect this approach to run faster than the current implementation. -- ___

[issue10042] total_ordering

Nick Coghlan added the comment: NotImplemented is a speed and maintainability hack - the runtime cost and additional code complexity involved in doing the same operator signalling via exceptions would be prohibitive (check Objects/abstract.c in the CPython source if you want the gory details)

[issue10042] total_ordering

Francesco Ricciardi added the comment: On the one hand, it's not just a matter of total_ordering and rich comparison operators, because all user defined operators may return NotImplemented when they get types that they don't know how to handle. On the other hand, if such a decision is taken,

[issue10042] total_ordering

Lennart Regebro added the comment: I was also surprised by the special return value, but it seems a bit overkill to change the implementation of rich comparison operators just because it's tricky to make a short and pretty class decorator that extends some operators to all operators. :) And

[issue10042] total_ordering

Francesco Ricciardi added the comment: I think the whole issue is indeed how NotImplemented is treated. To me saying that 'not NotImplemented' is True is wrong. About the stack overflow I found there are various possible fixes, however none will nice. By definition, NotImplemented is the way

[issue10042] total_ordering

Alexander Boyd added the comment: Ok. Yeah, I won't argue that it's pretty :-) -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue10042] total_ordering

Lennart Regebro added the comment: Yeah, I can't say it's pretty though. :) Anyway this is an issue for 3.2 and 2.7 as well, then, so I add them back. -- versions: +Python 2.7, Python 3.2 ___ Python tracker _

[issue10042] total_ordering

Alexander Boyd added the comment: That's my point. My version, sane_total_ordering.py, fixes this by using traditional functions and explicit NotImplemented checks. -- ___ Python tracker _

[issue10042] total_ordering

Lennart Regebro added the comment: Ah! I see how you mean. The problem isn't just if you turn the conversion around from self > other to other < self. The problem in fact appears when a rich text function uses the <>!= operators on self directly. I tried a version which uses the __xx__ operat

[issue10042] total_ordering

Alexander Boyd added the comment: I've attached a file demonstrating the stack overflow. It assumes total_ordering has been defined as per new_total_ordering.py. -- Added file: http://bugs.python.org/file21712/new_total_ordering_overflow.py ___ Pyth

[issue10042] total_ordering

Lennart Regebro added the comment: I'm attaching a file with the example classes returning NotImplemented, and a different implementation of a total ordering, as an example of how returning NotImplemented by one class will give the chance to the other class. This is the ultimate cause of the

[issue10042] total_ordering

Lennart Regebro added the comment: We *do* care about NotImplemented, that's the whole point of this bug report. I don't see how this is a problem in the new_total_ordering.py example. Can you give an example of when you get a stack overflow? The examples in new_total_ordering are in themselv

[issue10042] total_ordering

Raymond Hettinger added the comment: > I am curious, however, as to how this could break existing code. > It seems like code that relies on a stack overflow is already > broken as it is. Probably so. I worry about changes in semantics but it might be harmless. -- __

[issue10042] total_ordering

Alexander Boyd added the comment: Ok. I did write that against Python 2, so I wasn't aware of __eq__ and __ne__. I'll keep that in mind. I am curious, however, as to how this could break existing code. It seems like code that relies on a stack overflow is already broken as it is. --

[issue10042] total_ordering

Raymond Hettinger added the comment: It may seem pointless, but it takes less than a minute to do it and it would be both faster and clearer to do it manually. There's a limit to how much implicit code generation can or should be done automatically. Also, I'm not too keen on the feature cr

[issue10042] total_ordering stack overflow

Alexander Boyd added the comment: But it seems pointless to force someone to implement all of the rich comparison methods when they may want to do something as simple as this: class Foo: ... def __lt__(self, other): if not isinstance(other, Foo): return NotImplement

[issue10042] total_ordering stack overflow

Raymond Hettinger added the comment: I'm not sure that we really care about handling NotImplemented (practicality beats purity). At some point, if someone writing a class wants complete control over the rich comparison methods, then they're going to have to write those methods. -- a

[issue10042] total_ordering stack overflow

Alexander Boyd added the comment: This is not fixed. The accepted fix doesn't take NotImplemented into account, with the result that comparing two mutually-incomparable objects whose ordering operations were generated with total_ordering causes a stack overflow instead of the expected "TypeEr

[issue10042] total_ordering stack overflow

Roundup Robot added the comment: New changeset 94c158199277 by Éric Araujo in branch '2.7': Fix the total_ordering decorator to handle cross-type comparisons http://hg.python.org/cpython/rev/94c158199277 -- nosy: +python-dev stage: -> committed/rejected status: open -> closed

[issue10042] total_ordering stack overflow

Raymond Hettinger added the comment: Éric, would you like to apply this to 2.7? -- assignee: rhettinger -> eric.araujo ___ Python tracker ___ ___

[issue10042] total_ordering stack overflow

Éric Araujo added the comment: FWIW, I just tested svnmerging the revision, the patch applied with minor merge conflicts and the test suite passes. -- ___ Python tracker ___ __

[issue10042] total_ordering stack overflow

Changes by Raymond Hettinger : -- priority: normal -> low ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue10042] total_ordering stack overflow

Changes by Alexander Belopolsky : -- type: crash -> behavior versions: -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailin

[issue10042] total_ordering stack overflow

Changes by Éric Araujo : -- status: closed -> open versions: +Python 2.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue10042] total_ordering stack overflow

Lennart Regebro added the comment: This also affects Python 2.7, where it hasn't been fixed. Maybe reopen it? -- nosy: +lregebro ___ Python tracker ___ _

[issue10042] total_ordering stack overflow

Raymond Hettinger added the comment: Thanks for the report and patch. Fixed. See r87853. -- ___ Python tracker ___ ___ Python-bugs-

[issue10042] total_ordering stack overflow

Changes by Raymond Hettinger : -- Removed message: http://bugs.python.org/msg125757 ___ Python tracker ___ ___ Python-bugs-list mailin

[issue10042] total_ordering stack overflow

Raymond Hettinger added the comment: Thanks for the report and patch. Fixed. rSee 87853. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___

[issue10042] total_ordering stack overflow

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue10042] total_ordering stack overflow

Raymond Hettinger added the comment: Thanks, this is a good idea. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue10042] total_ordering stack overflow

Changes by Benjamin Peterson : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue10042] total_ordering stack overflow

Francesco Ricciardi added the comment: Attached there is a solution of the problem, by implementing each comparison only with the class __xx__ and __eq__ operators. Also in the file there is a complete test suite for it. -- Added file: http://bugs.python.org/file19145/new_total_orderi

[issue10042] total_ordering stack overflow

New submission from Francesco Ricciardi : Tested with version 3.2a2. Not tested on version 2.7. The current implementation of functools.total_ordering generates a stack overflow because it implements the new comparison functions with inline operator, which the Python interpreter might reverse