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.
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> > _______________________________________ >
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
