Why doesn't `functools.total_ordering` use the existing ordering methods?
Hello, Today I was trying to use `total_ordering` for the first time. I was expecting that in order to implement e.g. `x > y` it would do `not x < y and not x == y`, assuming that `__lt__` and `__eq__` are defined. But I see it just does `y < x`, which is problematic. For example if you have a class that is decorated by `total_ordering`, and implements only `__lt__` and `__eq__`, then trying to do `x < y` will result in infinite recursion. Why not have `total_ordering` work in the way I suggested? Ram.
On Apr 25, 2011, at 11:43 AM, cool-RR wrote:
Today I was trying to use `total_ordering` for the first time. I was expecting that in order to implement e.g. `x > y` it would do `not x < y and not x == y`, assuming that `__lt__` and `__eq__` are defined.
This was fixed. The current code has: convert = { '__lt__': [('__gt__', lambda self, other: not (self < other or self == other)), ('__le__', lambda self, other: self < other or self == other), ('__ge__', lambda self, other: not self < other)], '__le__': [('__ge__', lambda self, other: not self <= other or self == other), ('__lt__', lambda self, other: self <= other and not self == other), ('__gt__', lambda self, other: not self <= other)], '__gt__': [('__lt__', lambda self, other: not (self > other or self == other)), ('__ge__', lambda self, other: self > other or self == other), ('__le__', lambda self, other: not self > other)], '__ge__': [('__le__', lambda self, other: (not self >= other) or self == other), ('__gt__', lambda self, other: self >= other and not self == other), ('__lt__', lambda self, other: not self >= other)] }
Why not have `total_ordering` work in the way I suggested?
To avoid needless posts, you should use the tracker. Raymond
On Mon, Apr 25, 2011 at 20:43, cool-RR <cool-rr@cool-rr.com> wrote:
This has been partly fixed for Python 3.2, although it can still happen if you compare two types that both use the total_ordering decorator. See http://bugs.python.org/issue10042 . -- Lennart Regebro: http://regebro.wordpress.com/ Porting to Python 3: http://python3porting.com/
On Apr 25, 2011, at 11:43 AM, cool-RR wrote:
Today I was trying to use `total_ordering` for the first time. I was expecting that in order to implement e.g. `x > y` it would do `not x < y and not x == y`, assuming that `__lt__` and `__eq__` are defined.
This was fixed. The current code has: convert = { '__lt__': [('__gt__', lambda self, other: not (self < other or self == other)), ('__le__', lambda self, other: self < other or self == other), ('__ge__', lambda self, other: not self < other)], '__le__': [('__ge__', lambda self, other: not self <= other or self == other), ('__lt__', lambda self, other: self <= other and not self == other), ('__gt__', lambda self, other: not self <= other)], '__gt__': [('__lt__', lambda self, other: not (self > other or self == other)), ('__ge__', lambda self, other: self > other or self == other), ('__le__', lambda self, other: not self > other)], '__ge__': [('__le__', lambda self, other: (not self >= other) or self == other), ('__gt__', lambda self, other: self >= other and not self == other), ('__lt__', lambda self, other: not self >= other)] }
Why not have `total_ordering` work in the way I suggested?
To avoid needless posts, you should use the tracker. Raymond
On Mon, Apr 25, 2011 at 20:43, cool-RR <cool-rr@cool-rr.com> wrote:
This has been partly fixed for Python 3.2, although it can still happen if you compare two types that both use the total_ordering decorator. See http://bugs.python.org/issue10042 . -- Lennart Regebro: http://regebro.wordpress.com/ Porting to Python 3: http://python3porting.com/
participants (3)
-
cool-RR -
Lennart Regebro -
Raymond Hettinger