[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Robert Collins added the comment: Thanks for the patch; applied to 3.4 and up. -- nosy: +rbcollins resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker ___

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Roundup Robot added the comment: New changeset f5069e6e4229 by Robert Collins in branch '3.4': Issue #4395: Better testing and documentation of binary operators. https://hg.python.org/cpython/rev/f5069e6e4229 New changeset b9a0165a3de8 by Robert Collins in branch '3.5': Issue #4395: Better testi

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Serhiy Storchaka added the comment: LGTM. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Martin Panter added the comment: This updated patch adds the clarification about NotImplemented. -- Added file: http://bugs.python.org/file39958/default-ne-reflected-priority.v4.patch ___ Python tracker ___

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Serhiy Storchaka added the comment: Added comments on Rietveld. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Martin Panter added the comment: Nick seemed to approve of this, so perhaps it is ready to commit? The new patch just resolves a minor conflict with the current code. -- stage: patch review -> commit review versions: +Python 3.6 Added file: http://bugs.python.org/file39954/default-ne-r

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Martin Panter added the comment: Issue 21408 has been committed to 3.4 and 3.5 branches, so my patch can now be considered to document the newly fixed behaviour. -- ___ Python tracker __

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Serhiy Storchaka added the comment: See also issue23326. -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Martin Panter added the comment: Adding a new patch that just fixes the typo error in the first patch -- Added file: http://bugs.python.org/file37859/default-ne-reflected-priority.v2.patch ___ Python tracker __

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Martin Panter added the comment: The reference to @functools.total_ordering was actually already there; I just moved it into the paragraph about relationships between the operators. I should also point out that my description of the default __ne__() assumes that Issue 21408 is resolved; the cu

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Nick Coghlan added the comment: While Martin's patch doesn't cover all the vagaries of comparison operations discussed above, it fixes the outright error, and provides an appropriate cross-reference to functools.total_ordering. -- ___ Python tracker

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Berker Peksag : -- nosy: +berker.peksag ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Andrew Svetlov : -- stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Andrew Svetlov : -- versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 ___ Python tracker ___ ___ Python-bugs-list ma

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Martin Panter added the comment: Here is a patch that documents the default object.__ne__() implementation. It also documents the subclass priority rules for the reflected comparison methods, which is raised in Issue 22052. I have made some more tests to verify the relationships exists from __

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Mark Dickinson : -- priority: low -> normal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Mark Dickinson added the comment: Issue #17151 closed as a duplicate of this one. -- nosy: +kushou, mark.dickinson ___ Python tracker ___ _

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Nick Coghlan : -- nosy: +antocuni ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

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

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Ezio Melotti : -- versions: +Python 3.3 -Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Éric Araujo : -- nosy: +d...@python -georg.brandl stage: -> needs patch type: -> behavior versions: +Python 3.2 ___ Python tracker ___ ___

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Raymond Hettinger : -- assignee: rhettinger -> terry.reedy priority: normal -> low ___ Python tracker ___ ___ Python-bugs-li

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Chris Rebert : -- nosy: +cvrebert ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Michael K. Edwards added the comment: It would also be useful to point out that there is a shortcut in the interpreter itself (PyObject_RichCompareBool, in object.c) which checks the equivalent of id(a) == id(b) and bypasses __eq__/__ne__ if so. Since not every call to __eq__ passes through thi

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Michael K. Edwards added the comment: The implementation you are looking for is in object_richcompare, in http://svn.python.org/projects/python/branches/py3k/Objects/typeobject.c . It would be most accurate to say something like: The "object" base class, from which all user-defined classes

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Changes by Raymond Hettinger : -- assignee: georg.brandl -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Terry J. Reedy added the comment: The situation appears to be at least slightly different from what Guido stated. In 3.x, all classes subclass object, which has .__ne__, so if that stopped inferred != behavior, it would never happen. >>> class A: def __eq__(s,p): return 1 >>> id(object

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Raymond Hettinger added the comment: One other thought: The __ne__ method follows automatically from __eq__ only if __ne__ isn't already defined in a superclass. So, if you're inheriting from a builtin, it's best to override both. -- nosy: +rhettinger

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Terry J. Reedy added the comment: The current paragraph "There are no implied relationships among the comparison operators. The truth of x==y does not imply that x!=y is false. Accordingly, when defining __eq__(), one should also define __ne__() so that the operators will behave as expected. " i

[issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__

Michael K. Edwards <[EMAIL PROTECTED]> added the comment: It would be really useful to explain, right in this section, why __ne__ is worth having. Something along these lines (based on the logic from Python 2.x -- modify as necessary): The values most commonly returned by the rich comparison