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
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 rep...@bugs.python.org
http://bugs.python.org/issue4395
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 rep...@bugs.python.org
Serhiy Storchaka added the comment:
LGTM.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
Serhiy Storchaka added the comment:
Added comments on Rietveld.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
___
Python-bugs-list
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
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 rep...@bugs.python.org
http://bugs.python.org/issue4395
Serhiy Storchaka added the comment:
See also issue23326.
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
___
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 rep...@bugs.python.org
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
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
Changes by Berker Peksag berker.pek...@gmail.com:
--
nosy: +berker.peksag
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
___
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
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
Mark Dickinson added the comment:
Issue #17151 closed as a duplicate of this one.
--
nosy: +kushou, mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
Changes by Mark Dickinson dicki...@gmail.com:
--
priority: low - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
___
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
___
Python-bugs-list mailing
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +antocuni
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
___
Python-bugs-list mailing
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
___
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
___
Python-bugs-list
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
versions: +Python 3.3 -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
___
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +d...@python -georg.brandl
stage: - needs patch
type: - behavior
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: rhettinger - terry.reedy
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
Changes by Chris Rebert pyb...@rebertia.com:
--
nosy: +cvrebert
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
___
Python-bugs-list
Michael K. Edwards m.k.edwa...@gmail.com 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
Michael K. Edwards m.k.edwa...@gmail.com 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
Terry J. Reedy tjre...@udel.edu 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
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
--
assignee: georg.brandl - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4395
___
Terry J. Reedy tjre...@udel.edu 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
Raymond Hettinger rhettin...@users.sourceforge.net 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
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):
doctext
The values most commonly returned by the rich
33 matches
Mail list logo
