Annoying behaviour of the != operator

Peter Hansen peter at
Wed Jun 8 18:48:54 EDT 2005

Christopher Subich wrote:
> Perhaps the language should offer 
> the sensible default of (!=) == (not ==) if one of them but not the 
> other is overriden, but still allow overriding of both.

I believe that's exactly what Jordan is promoting and, having been 
bitten in exactly the same way I would support the idea.  On the other 
hand, I was bitten only _once_ and I suspect Jordan will never be bitten 
by it again either.  It's pretty hard to forget this wart once you 
discover it, but I think the real reason to want to have it excised is 
that a large number of people will have to learn this the hard way, 
documentation (thankfully) not being shoved down one's throat as one 
starts intrepidly down the road of overriding __eq__ for the first time.

> This would technically break backwards compatibilty, because it changes 
> default behavior, but I can't think of any good reason (from a python 
> newbie perspective) for the current counterintuitive behavior to be the 
> default.  Possibly punt this to Python 3.0?

I'd support an effort to fix it in 2.5 actually.  I suspect nobody will 
pipe up with code that would actually be broken by it, though some code 
(as John Roth points out) doesn't *need* to have the automatic __ne__ 
even if it wouldn't break because of it.


More information about the Python-list mailing list