#15904: Defining __eq__ without defining __ne__ or __cmp__: sage/combinat
-------------------------+-------------------------------------------------
Reporter: darij | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.2
Component: | Keywords: sage-combinat, equality,
combinatorics | inheritance
Merged in: | Authors:
Reviewers: | Report Upstream: N/A
Work issues: | Branch:
Commit: | Dependencies:
Stopgaps: |
-------------------------+-------------------------------------------------
I think one should always at least one of `__ne__` and `__cmp__` on a
class when one defines `__eq__`, unless one really wants to have `!=` to
behave differently from the negation of `==` (or one is happy with the
`__ne__` inherited from the superclass; but then why would one redefine
`__eq__` to begin with?):
{{{
sage: ContreTableaux(4) == ContreTableaux(4)
True
sage: ContreTableaux(4) != ContreTableaux(4)
True
}}}
or also (here the `!=` is inherited from `CombinatorialObject`):
{{{
sage: Core([1,1],3) != Core([1,1],4)
False
sage: Core([1,1],3) == Core([1,1],4)
False
}}}
Here is a result of searching for this antipattern in the sage/combinat
subfolder:
https://www.dropbox.com/s/lca1yfw1qsz6ycy/ne.txt
Some of these do define `__cmp__`, but redefining `__ne__` might lead to a
speedup, so I kept them in the file even if these are not bugs per se.
Should we just fix them all robotically?
--
Ticket URL: <http://trac.sagemath.org/ticket/15904>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
