Peter Hansen wrote: > I can see only one comment that seems to describe that situation, where it refers to "IEEE 754 floating point numbers do not satisfy [== being the complement of !=]". > > (Though that may be justification enough for the feature...)
To my naive eye, that possibility seems like justification for the language to not -enforce- that (not (a == b)) == (a != b), but for the vast majority of cases this is true. 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. 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? -- http://mail.python.org/mailman/listinfo/python-list