[Python-Dev] Assumed reflexivity of rich comparison operators
Jared Flatow
jflatow at northwestern.edu
Fri Jun 6 22:44:14 CEST 2008
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
More information about the Python-Dev
mailing list