Why does __ne__ exist?

[Chris Angelico]

On Mon, Jan 8, 2018 at 11:35 AM, Ben Finney via Python-list
<python-list at python.org> wrote:
> Chris Angelico <rosuav at gmail.com> writes:
>
>> On Mon, Jan 8, 2018 at 10:55 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
>> > 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.
>
> That is an inconsistency, I agree.
>
>> 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.
>
> I think “reject unless absolutely needed” is an unreasonably high bar,
> which would disqualify most Python language features. So I don't know
> why you expect this to be so especially strongly argued.

True, I exaggerated a bit. But do you think that, had __ne__ not
existed for years, its addition could be justified?

>> Make sure you mention the potential confusion when subclassing.
>
> For example, that would alsop be a problem for multiple inheritance. Not
> “absolutely needed”, and high risk of confusion when subclassing. Do you
> think that multiple inheritance would thereby also not be allowed today?
>
> If you consider that a different case, why?

There's a LOT that you can do usefully with MI that you can't do
without it. Having spent a few years (many years ago) working with
Java, I appreciate the ability to inherit from more than one class.
Does it have to be done the way Python currently does it? No. But one
way or another, it's a massively useful feature.

(You're right that "absolutely needed" is too high a bar, but
hyperbole aside, I do think that MI hits a higher mark than __ne__
does.)

ChrisA