Jordan Rastrick wrote: > Unless someone can explain some sort of problem that arises from having > != take advantage of a __eq__ method where present, I'd suggest that it > should do so in Python 2.5.
If you're serious about this proposal, please formalize it in a PEP. Things to specify: How extensive are these changes? Is it just !=, or if __eq__ is not defined, will it be equal to "not __ne__()"? __lt__/__gt__? __le__/__ge__? Do you simulate __le__ with '__lt__ or __eq__'? How about __lt__ with '__le__ and __ne__'? > I'd be surprised if such a change broke so much as a single line of > existing Python code. Well, since it currently raises an error when __ne__ is not defined, I'd say your right on that account. The only corner case is when people would rely on 'a != b' to be implicitly translated to 'b != a'. If 'a != b' gets translated to 'not a == b', this may change semantics if the two are not equivalent. -- http://mail.python.org/mailman/listinfo/python-list
