Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #73757 > unrolled thread

unorderable error: less ok, equal ok, less-or-equal gives unorderable error!

Back to article view | Back to comp.lang.python

Contents

  unorderable error: less ok, equal ok, less-or-equal gives unorderable error! RainyDay <andrei.avk@gmail.com> - 2014-06-30 12:12 -0700
    Re: unorderable error: less ok, equal ok, less-or-equal gives unorderable error! Peter Otten <__peter__@web.de> - 2014-06-30 21:34 +0200
      Re: unorderable error: less ok, equal ok, less-or-equal gives unorderable error! RainyDay <andrei.avk@gmail.com> - 2014-06-30 13:29 -0700
    Re: unorderable error: less ok, equal ok, less-or-equal gives unorderable error! Ethan Furman <ethan@stoneleaf.us> - 2014-06-30 12:52 -0700
    Re: unorderable error: less ok, equal ok, less-or-equal gives unorderable error! Peter Otten <__peter__@web.de> - 2014-07-01 14:43 +0200

#73757 — unorderable error: less ok, equal ok, less-or-equal gives unorderable error!

Hi, in python 3.4.1, I get this surpising behaviour:

>>> l=Loc(0,0)
>>> l2=Loc(1,1)
>>> l>l2
False
>>> l<l2
True
>>> l<=l2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: Loc() <= Loc()
>>> l==l2
False
>>> l<l2 or l==l2
True

Loc implements both __lt__ and __eq__, which should be enough (?),
but even after I've added __lte__, I still have the error.

implementation:

class Loc:
    def __init__(self, x, y):
        self._loc = x, y
        self.x, self.y = x, y

    def __eq__(self, other):
        return self._loc == getattr(other, "_loc", None)

    def __lt__(self, other):
        return self._loc < other._loc

 - andrei

[toc] | [next] | [standalone]

#73759

RainyDay wrote:

> Hi, in python 3.4.1, I get this surpising behaviour:
> 
>>>> l=Loc(0,0)
>>>> l2=Loc(1,1)
>>>> l>l2
> False
>>>> l<l2
> True
>>>> l<=l2
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: unorderable types: Loc() <= Loc()
>>>> l==l2
> False
>>>> l<l2 or l==l2
> True
> 
> Loc implements both __lt__ and __eq__, which should be enough (?),

These two methods should be sufficient if you use the 
functools.total_ordering class decorator, see

https://docs.python.org/dev/library/functools.html#functools.total_ordering

> but even after I've added __lte__, I still have the error.

There is no special method of that name; it should probably be __le__().

> 
> implementation:
> 
> class Loc:
>     def __init__(self, x, y):
>         self._loc = x, y
>         self.x, self.y = x, y
> 
>     def __eq__(self, other):
>         return self._loc == getattr(other, "_loc", None)

Note that None is not a good default when _loc is expected to be a tuple:

>>> None < ()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: NoneType() < tuple()

> 
>     def __lt__(self, other):
>         return self._loc < other._loc
> 
>  - andrei

[toc] | [prev] | [next] | [standalone]

#73763

On Monday, June 30, 2014 3:34:25 PM UTC-4, Peter Otten wrote:
> RainyDay wrote:
> 
> 
> 
> > Hi, in python 3.4.1, I get this surpising behaviour:
> 
> > 
> 
> >>>> l=Loc(0,0)
> 
> >>>> l2=Loc(1,1)
> 
> >>>> l>l2
> 
> > False
> 
> >>>> l<l2
> 
> > True
> 
> >>>> l<=l2
> 
> > Traceback (most recent call last):
> 
> >   File "<stdin>", line 1, in <module>
> 
> > TypeError: unorderable types: Loc() <= Loc()
> 
> >>>> l==l2
> 
> > False
> 
> >>>> l<l2 or l==l2
> 
> > True
> 
> > 
> 
> > Loc implements both __lt__ and __eq__, which should be enough (?),
> 
> 
> 
> These two methods should be sufficient if you use the 
> 
> functools.total_ordering class decorator, see


Thanks! I literally failed to read one more paragraph in a SO answer
which referenced this decorator. I really need to start reading those
paragraphs, they often provide answers...

> > but even after I've added __lte__, I still have the error.
> 
> 
> 
> There is no special method of that name; it should probably be __le__().


Right, I used lte in django and assumed they were consistent with python.
 
> >     def __eq__(self, other):
> 
> >         return self._loc == getattr(other, "_loc", None)
> 
> 
> 
> Note that None is not a good default when _loc is expected to be a tuple:
> 

I'm only using None in equality comparison, it's never a default value of
_loc itself, so this should be ok because it'll compare to all other object
types and correctly say they're unequal.

 
 - andrei

[toc] | [prev] | [next] | [standalone]

#73764

On 06/30/2014 12:34 PM, Peter Otten wrote:
> RainyDay wrote:
>>
>>      def __eq__(self, other):
>>          return self._loc == getattr(other, "_loc", None)
>
> Note that None is not a good default when _loc is expected to be a tuple:

In this case None is not being returned, but will be comparid with self._loc, so RainyDay is good there.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#73787

Ethan Furman wrote:

> On 06/30/2014 12:34 PM, Peter Otten wrote:
>> RainyDay wrote:
>>>
>>>      def __eq__(self, other):
>>>          return self._loc == getattr(other, "_loc", None)
>>
>> Note that None is not a good default when _loc is expected to be a tuple:
> 
> In this case None is not being returned, but will be comparid with
> self._loc, so RainyDay is good there.

RainyDay wrote:

> I'm only using None in equality comparison, it's never a default value of
> _loc itself, so this should be ok because it'll compare to all other
> object types and correctly say they're unequal.

Yes, sorry. I read what I expected rather than what was there.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web