Jordan Rastrick wrote:
> I just spent a long, long time tracking down a bug in a program that
> results from this behaviour.
>
> Surely the != operator should, if no __ne__ method is present for
> either object, check to see if an __eq__ method is defined, and if so,
> return its negation?
>
> Actually, that brings me to a wider question - why does __ne__ exist at
> all? Surely its completely inconsistent and unnessecary to have
> seperate equals and not equals methods on an object? a != b should just
> be a short way of writing not (a == b). The fact the two can give a
> different answer seems to me to be utterly unintuitive and a massive
> pitfall for beginners (such as myself).
surely reading the documentation would be a great way to avoid
pitfalls?
http://docs.python.org/ref/customization.html
__lt__, __le__ (etc)
New in version 2.1. These are the so-called "rich comparison" methods,
and are called for comparison operators in preference to __cmp__() below.
/.../
There are no implied relationships among the comparison operators. The
truth of x==y does not imply that x!=y is false. Accordingly, when defining
__eq__, one should also define __ne__ so that the operators will behave
as expected.
/.../
__cmp__
Called by comparison operations if rich comparison (see above) is not
defined. Should return a negative integer if self < other, zero if self
== other, a positive integer if self > other. /.../
for a number of situations where __ne__ cannot be derived from __eq__,
see:
http://www.python.org/peps/pep-0207.html
</F>0
--
http://mail.python.org/mailman/listinfo/python-list
