This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Suggestion: change default behavior of __ne__
Type: behavior Stage:
Components: Versions:
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, cvp
Priority: normal Keywords:

Created on 2008-07-01 21:36 by cvp, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg69078 - (view) Author: (cvp) Date: 2008-07-01 21:36
After defining my own __eq__ method for a class that judged equality
based on a 'name' variable, imagine my surprise to see this:

In [20]: my_graph.edges[-1].end == my_graph.vertices[-1]
Out [20]: True

In [21]: my_graph.edges[-1].end != my_graph.vertices[-1]
Out [21]: True

...all because I forgot to modify __ne__ as well.

I think __ne__ should be changed to 'not __eq__' for the sake of
msg69080 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-07-01 23:10
Sorry, this is documented [1], and it unlikely to ever be changed. 

msg69081 - (view) Author: (cvp) Date: 2008-07-01 23:20
But why not? Laziness or something? Or "just cuz?"


On Tue, Jul 1, 2008 at 4:11 PM, Benjamin Peterson <>

> Benjamin Peterson <> added the comment:
> Sorry, this is documented [1], and it unlikely to ever be changed.
> [1]
> ----------
> nosy: +benjamin.peterson
> resolution:  -> rejected
> status: open -> closed
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
msg69082 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-07-01 23:20
1) It's much more flexible.
2) It would break compatibility.
msg69083 - (view) Author: (cvp) Date: 2008-07-02 00:33
1) I didn't say that the option to edit __ne__ should be removed, only that
it'd be both more consistent and convenient to change the meaning to
something relative by default.

2) So long as the old code defines __ne__, which I'm guessing is the code
that you're telling me will break, I still don't see how this will cause any
issues whatsoever. I mean, I guess it could mess up some people who were
using '!=' to be *intentionally* synonymous with 'is not', but that's
awfully contrived for a language that's supposed to be well-known for being
straight-forward and easily readable.

Date User Action Args
2022-04-11 14:56:36adminsetgithub: 47504
2008-07-02 00:34:58cvpsetfiles: - unnamed
2008-07-02 00:34:53cvpsetfiles: - unnamed
2008-07-02 00:33:55cvpsetfiles: + unnamed
messages: + msg69083
2008-07-01 23:20:57benjamin.petersonsetmessages: + msg69082
2008-07-01 23:20:09cvpsetfiles: + unnamed
messages: + msg69081
2008-07-01 23:11:00benjamin.petersonsetstatus: open -> closed
resolution: rejected
messages: + msg69080
nosy: + benjamin.peterson
2008-07-01 21:36:17cvpcreate