Why does __ne__ exist?

[Chris Angelico]

On Mon, Jan 8, 2018 at 10:55 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
> Chris Angelico <rosuav at gmail.com> writes:
>
>> So, yeah, sounds like it's basically historical. I'm still not sure
>> why it was done in the first place, but it looks like it's the sort of
>> thing that wouldn't be done now.
>
> I'm not understanding why you speculate that it wouldn't be done today.
>
> We've established that it is useful to allow data types to define their
> own meaning of “equal” and “not equal”, like many other operations. Is
> that not good enough reason to allow it still?

The fact that container types can define "contains" but can't define
"doesn't contain", and that (as of Py3) there's proper default
handling, suggests that it's not as big a priority now.

Let's put it this way. Suppose that __eq__ existed and __ne__ didn't,
just like with __contains__. Go ahead: sell the notion of __ne__.
Pitch it, show why we absolutely need to allow this. Make sure you
mention the potential confusion when subclassing. Be sure to show why
it's okay for "not in" to force to boolean but "==" should allow any
return value.

ChrisA