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. -Peter -- http://mail.python.org/mailman/listinfo/python-list
