assymetry between a == b and a.__eq__(b)

[Nick Coghlan]

Peter Otten wrote:
> Tim Peters wrote:
> 
> 
>>See the Python (language, not library) reference manual, section 3.3.8
>>("Coercion rules"), bullet point starting with:
>>
>>    Exception to the previous item: if the left operand is an
>>    instance of a built-in type or a new-style class, and the right
>>    operand is an instance of a proper subclass of that type or
>>    class, ...
> 
> 
> So that is settled then. Not the most likely place to investigate when one
> has just read that "Arguments to rich comparison methods are never coerced"
> in 3.3.1 ("Basic customization"), though.

<Heh - just reread this, and realised my reply below misses the point. You're 
right that the subsection heading is a little misleading. . .>

Nothing is getting coerced. It's just that "A binop B" gets translated to a 
method call differently depending on the types of A and B. The options being:

A.__binop__(B)  # 1 - the usual case
B.__binop__(A)  # 2.1 - commutative op, and B is a proper subclass of A
B.__rbinop__(A) # 2.2 - possibly non-commutative op, and B is a proper subclass of A

This is so that things like the following work:

.>>> class SillyAdd(long):
....   __add__ = long.__mul__
....   __radd__ = __add__
....
.>>> a = SillyAdd(4)
.>>> a
.4L
.>>> a + 5
.20L
.>>> 5 + a
.20L

Cheers,
Nick.