Как не прописывать действие для каждой операции сравнения?

Question

[Валерий Рябошапко]

Приветствую.

Пишу свой класс и хочу прописать для него такие методы как __lt__, __le__, __ge__, __gt__, __eq__, но не хочу писать десяток одинаковых методов, которые отличаются на один-два знака. Подскажите, как всё это сделать красиво и элегантно?

Сейчас пытаюсь что-то намудрить с лямбдой и переменной __name__ и с атрибутом __dict__, но пока результата нет.

Может, кто-то уже делал такое?

Comments

[Роман]

А python разве не умеет делать типа __lt__ = lambda x: not self.__ge__(x)? Мне казалось что я читал, что можно определить, например, "<", и тогда другие операции python _сам_ определит автоматом: "a >= b" == not "a < b"; "a == b" == "a >= b" and "b >= a" и т.д. Не оптимально, конечно, но зато не требует писать десяток почти одинаковых методов.

[Валерий Рябошапко]

Роман: вряд ли это так, хотя бы потому, что это противоречит дзену пайтона (явное лучше, чем неявное). Но попробую поискать.

[DDDsa]

Роман: Часть методов python действительно неявно определяет по аналогии, но не все и чтобы это применять - надо разбираться. Если вы определяете __lt__ (<), то неявно автоопределится __gt__ (>), но не __ge__ (>=) и __le__ (<=). Даже если определен __eq__ - все равно. Определение __eq__ (==), кстати, не дает вам автоматически __ne__(!=).

С другой стороны, если определены __len__ и __getitem__, то __iter__ прописывать не надо. И т д

[Валерий Рябошапко]

Даниил: ух ты, спасибо за объяснение. Про __iter__, вытекающий из __len__ и __getitem__ — очень логично и круто.

[Роман]

Даниил спасибо за разъяснение. Надо будет освежить память, и почитать документацию или книгу какую.

[abcd0x00]

Даниил:

Если вы определяете __lt__ (<), то неявно автоопределится __gt__ (>), но не __ge__ (>=) и __le__ (<=).

С чего вдруг там __gt__ определится? Если что-то не меньше, то это недостаточно для того, чтобы оно было больше.

Благо питон даёт удобный интерпретатор, в котором легко всё проверяется:

>>> class A:
...     def __lt__(self, v):
...         return hasattr(v, 'x')
... 
>>> class B:
...     x = 1
... 
>>> class C:
...     y = 1
... 
>>> a, b, c = A(), B(), C()
>>> 
>>> a < b
True
>>> a > b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() > B()
>>> a == b
False
>>> a != b
True
>>> a <= b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() <= B()
>>> a >= b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() >= B()
>>> 
>>> a < c
False
>>> a > c
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() > C()
>>> a == c
False
>>> a != c
True
>>> a <= c
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() <= C()
>>> a >= c
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() >= C()
>>>

[DDDsa]

abcd0x00:
Вот, что имеется в виду:

>>> class Test:
	def __init__(self,value):
		self._value = value
#
	def __lt__(self,other):
		if type(other) != Test:
			raise ValueError('comparing object must be of type Test')
		return self._value < other._value
... ... ... ... ... ... ... ... 
>>> a = Test(10)
>>> b = Test(20)
>>> a < b
True
>>> a > b
False
>>> a < 3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 7, in __lt__
ValueError: comparing object must be of type Test

[abcd0x00]

Даниил:

__gt__ не изменился:

>>> class Test:
...   def __init__(self,value):
...     self._value = value
...   
...   def __lt__(self,other):
...     if type(other) != Test:
...       raise ValueError('comparing object must be of type Test')
...     return self._value < other._value
... 
>>> a = Test(10)
>>> b = Test(20)
>>> a < b
True
>>> a > b
False
>>> a < 3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 7, in __lt__
ValueError: comparing object must be of type Test
>>> a > 3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: Test() > int()
>>>

[abcd0x00]

Даниил:

Вообще-то, он лезет проверять в __lt__ при > :

>>> class Test:
...   def __init__(self,value):
...     self._value = value
...   
...   def __lt__(self,other):
...     print('lt')
...     if type(other) != Test:
...       raise ValueError('comparing object must be of type Test')
...     return self._value < other._value
... 
>>> a = Test(10)
>>> b = Test(20)
>>> a < b
lt
True
>>> a > b
lt
False
>>>

[DDDsa]

abcd0x00: Эврика! : ) Именно это я и имел в виду, когда говорил "Если вы определяете __lt__ (<), то неявно автоопределится __gt__ (>)". Согласен, выражение немного некорректное, поскольку __gt__ все же не определяется (что несложно проверить при помощи a.__gt__(b) ). Правильнее выразиться так: "Если реализован метод __lt__, то класс будет поддерживать синтакс a < b, а также, неявно, синтакс a > b". Думаю, это всех устроит.

Суть этой фишки в том, чтобы не прописывать часть зеркальных методов при реализации взаимодействия экземпляров вашего класса друг с другом. Но опять же, чтобы это делать нужно в теме неплохо разбираться. Например, если определить __eq__, то будет корректно работать как a == b, так и a != b. А вот если определить только __ne__, то корректно будет работать само a != b, а a == b будет эквивалентно a is b.

[Роман]

abcd0x00 видимо о том и речь: определили только a < b, а для a > b будет использоваться b < a автоматически.

>>> class Test:
...     def __init__(self, value):
...         self.value = value
...     def __lt__(self, other):
...         print('lt')
...         print(self.value)
...         return self.value < other.value
...
>>> a = Test(10)
>>> b = Test(20)
>>> a < b
lt
10
True
>>> a > b
lt
20
False
>>>

Answer 1

[Vladimir Abiduev]

Наследование, настало твое время?

Наследуйтесь от базового типа, где уже есть схожие операции.
И еще вопрос - вам точно нужна своя структура данных? Потому что базовые типы овероптимизированы в отличии от подделок.

Смотреть, от чего наследоватся, можно, например, по __slots__, dir или в документации.

Comments

[Валерий Рябошапко]

Точно, а ведь отличная идея! Снаследоваться от того типа, по которому должна быть сортировка и просто добавить к нему полей.

[Валерий Рябошапко]

Для сложных данных неоднозначного уровня вложенности, вроде XML, данные, по которым должно идти сравнение, можно продублировать (дату или идентификатор) и записать в значение родительского класса.

[Vladimir Abiduev]

Валерий Рябошапко: но ведь xml надо парсить батарейками

[Валерий Рябошапко]

Vladimir Abiduev: да, парсить-то само собой, батарейками. Но после парсинга может получиться сложная вложенная структура. Даже не сильно вложенная, а пусть простой одномерный словарь. И вот нам надо эти данные иметь отсортированными по значению какого-то ключа, например, по дате. В таком случае тот класс, в котором мы будем хранить данные, наследуем от класса datetime.date и спокойно составляем из объектов этого класса список. Потом не менее спокойно этот список сортируем и выводим или итерируем его.