[Python-Dev] Assumed reflexivity of rich comparison operators

[Jared Flatow]

On Jun 6, 2008, at 3:24 PM, Guido van Rossum wrote:

> On Fri, Jun 6, 2008 at 1:10 PM, Jared Flatow  
> <jflatow at northwestern.edu> wrote:
>> PEP 207 (http://www.python.org/dev/peps/pep-0207/) states in the  
>> fourth
>> clause of the proposed resolutions to concerns:
>>
>> "The reflexivity rules *are* assumed by Python.  Thus, the  
>> interpreter may
>> swap y>x with x<y, y>=x with x<=y, and may swap the arguments of  
>> x==y and
>> x!=y."
>>
>> However, if this is the case, why does Python allow the definition  
>> of both
>> pairs of __le__, __ge__ and __lt__, __gt__ for a single class,  
>> since users
>> have no guarantee over which will be called? Currently, if I do not  
>> want x
>>> = y to mean the same thing as y <= x (and believe it or not I  
>>> believe I
>> have a good use case for doing this),
>
> I find it hard to believe that your users will be happy with that  
> though. :-)

In this case, I am my users and I would be very happy with it (but I  
won't try to justify it :).

>> there is no reliable way of doing this.
>
> Does it help if I tell you that for "x <binop> y" we always try
> x.__binop__(y) before trying y.__reverse_binop__(x), *except* in the
> case where y is an instance of a subclass of the class of x?

Yes, actually that explains quite a bit, and now I see that is the  
case I am dealing with. y is an instance of a subclass of x, but the  
class of x is the one that defines both the binops. I suppose it is  
too much to ask to only call the __reverse_binop__ if the subclass  
overrides it.

>> However, if the decision is to not allow users to do this at all  
>> using
>> operators (and force them to create specially named methods), what  
>> is the
>> point of allowing the definition of both?
>
> The same reason we allow (require) you to define __add__ and __radd_.
> It is quite possible that for any particular binary operation "x
> <binop> y", the class of x doesn't know how to implement it, and then
> the class of y is tried with the reversed operation.
>
>> It seems very confusing to me (and
>> indeed I was at first very confused what was going on), to tempt  
>> users to be
>> able to define both but give no promise that if they do, the  
>> appropriate one
>> will be called. Does anyone have a good explanation for this?
>
> I have explained it as well as I can.

Thanks very much, at least that is enough information to work around  
reliably.

jared