On Fri, Jun 6, 2008 at 1:10 PM, Jared Flatow <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com