Andrew Purdea wrote:
> Hello!
>   I can see that lists have implemented these methods in jython..
>   But i can not find any documentation on this. It looks like python 
> compares each element, and and when it finds a difference, it returns.
>   Where can  i find documenation on this?
In python 2.5 reference 3.4.1:

*__lt__*(       self, other)


*__le__*(       self, other)


*__eq__*(       self, other)


*__ne__*(       self, other)


*__gt__*(       self, other)


*__ge__*(       self, other)

    New in version 2.1. These are the so-called ``rich comparison''
    methods, and are called for comparison operators in preference to
    __cmp__() below. The correspondence between operator symbols and
    method names is as follows: |x<y| calls |x.__lt__(y)|, |x<=y| calls
    |x.__le__(y)|, |x==y| calls |x.__eq__(y)|, |x!=y| and |x<>y| call
    |x.__ne__(y)|, |x>y| calls |x.__gt__(y)|, and |x>=y| calls
    |x.__ge__(y)|. These methods can return any value, but if the
    comparison operator is used in a Boolean context, the return value
    should be interpretable as a Boolean value, else a TypeError will be
    raised. By convention, |False| is used for false and |True| for true.

    There are no implied relationships among the comparison operators.
    The truth of |x==y| does not imply that |x!=y| is false.
    Accordingly, when defining __eq__(), one should also define __ne__()
    so that the operators will behave as expected.

    There are no reflected (swapped-argument) versions of these methods
    (to be used when the left argument does not support the operation
    but the right argument does); rather, __lt__() and __gt__() are each
    other's reflection, __le__() and __ge__() are each other's
    reflection, and __eq__() and __ne__() are their own reflection.

    Arguments to rich comparison methods are never coerced. A rich
    comparison method may return |NotImplemented| if it does not
    implement the operation for a given pair of arguments.


> Will this behaviour remain in python for future releases?
I certainly hope so. A LOT of programs would suffer if not. I certainly 
have not seen any PEPs that discuss replacing or eliminating these.

-- 
Bob Gailer
510-978-4454 Oakland, CA
919-636-4239 Chapel Hill, NC


_______________________________________________
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Reply via email to