$ ~/Projects/cpython/3.4/python -c 'class Foo(object):    def __ne__(self, other):        return "yup"    def __eq__(self, other):        return "nope"class Bar(object):    pass        print(object() != Foo(), object() == Foo())print(Bar() != Foo(), Bar() == Foo())'yup nopeFalse nope$The output I would expect from this is    yup nope    yup nopeThat is, even when the type of the left-hand argument is not a base class of the type of the right-hand argument, delegation to the right-hand argument is sensible if the left-hand argument does not implement the comparison.Note that the output also demonstrates that this is already the behavior for `==`.  Only `!=` seems to suffer from this issue.

That's because the implicit default __ne__ on Bar returns the opposite of __eq__.

Why would an subclass of object that doesn't redefine either __eq__ or __ne__ have a different behavior for inequality than object itself? Bar never defined __eq__, so it shouldn't have an implicit __ne__ any more than object itself does...Saying that Bar has an implicit __ne__ that object doesn't is answering how this happens, but it's not a why; is there a reason why this should be the case, or is this a bug (either in spec or in code) that should be fixed?

The reason ``object() != Foo()`` "works" is that Foo is a subtype of object(), so the specialized __ne__ of Foo is called immediately without trying object.__ne__.I don't know whether it's a bug.

I don't think it's a bug.  The subclass-goes-first behavior is very intentional.  The implicit __ne__ returning the boolean inverse of __eq__ is what fooled me when I looked at it.Or did you mean that following the subclass rule in the case where object is the other class is possibly suspect?

The subclass behavior is a red herring.I meant maybe object.__ne__ should check if the other object has a __ne__ method before falling back on ``not object.__eq__()``.

Oh, I see.  Yes, that would seem more consistent.

There is a bit of analysis of the object.__ne__() implementation inIssue 4395. If my understanding is correct, I think it is a bug that object.__ne__(self, other) evaluates “not self == other”. It should evaluate “not self.__eq__(other)” instead, so that NotImplemented can be caught, allowing the reflected other.__ne__(self) method to be tried.

This patch should fix the problem I think. Before the __ne__() implementation was calling the “==” operator; now it calls the __eq__() method instead.Also includes extra test forIssue 4395 to avoid having conficting patches.

Particular case of this bug:>>> class A:...     def __eq__(self, other): return NotImplemented... >>> A().__eq__(object())NotImplemented>>> A().__ne__(object())TrueThe second result should be NotImplemented.Martin's patch LGTM except few style nitpicks to tests.

There are few incorrect implementations of __ne__ in the stdlib. Updated patch removes them. May be we should remove all implementations of __ne__ which are redundant now.

I looked over your __ne__ removals from the library, and they all seem sensible to me.

New changesete516badfd3b2 by Serhiy Storchaka in branch '3.4':Issue#21408: The default __ne__() now returns NotImplemented if __eq__()https://hg.python.org/cpython/rev/e516badfd3b2New changeset7e9880052401 by Serhiy Storchaka in branch 'default':Issue#21408: The default __ne__() now returns NotImplemented if __eq__()https://hg.python.org/cpython/rev/7e9880052401

Thank you for your contribution Martin.

New changeset3603bae63c13 by Serhiy Storchaka in branch 'default':Issue#23326: Removed __ne__ implementations.  Since fixing default __ne__https://hg.python.org/cpython/rev/3603bae63c13