[Python-Dev] Assumed reflexivity of rich comparison operators

[Guido van Rossum]

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. :-)

> 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?

> 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.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)