Why does __ne__ exist?
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__