classification
Title: Suggestion: change default behavior of __ne__
Type: behavior Stage:
Components: Versions:
process
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 2008-07-02 00:34 by cvp. 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
consistency.
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. 

[1] http://docs.python.org/ref/customization.html
msg69081 - (view) Author: (cvp) Date: 2008-07-01 23:20
But why not? Laziness or something? Or "just cuz?"

-Constantine

On Tue, Jul 1, 2008 at 4:11 PM, Benjamin Peterson <report@bugs.python.org>
wrote:

>
> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>
> Sorry, this is documented [1], and it unlikely to ever be changed.
>
> [1] http://docs.python.org/ref/customization.html
>
> ----------
> nosy: +benjamin.peterson
> resolution:  -> rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3254>
> _______________________________________
>
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.

-Constantine
History
Date User Action Args
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