[python] сложение классов

В python принят duck typing. То есть лучше ловить эксепшн, который происходит во время попытки сложить A и B (если их, действительно, нельзя сложить).

delete_comment.jsp


Да не, я не могу понять, как в __add__ узнать, что аргументами сложения являются экземпляры разных классов, то есть:

A + A = success
A + B = raise TypeError

P.S. Или надо подобное делать по-другому ?

Почему не сравнить типы через type(obj), type(self)?

def __add__(self, other):
  if type(self) != type(other):
    raise TypeError("undefined addition: %s, %s" % (type(self), type(other)))
  ...

?

P.S. Про какой из питонов речь, кстати?

isinstance. Но это нужно делать по-другому.

P.S. В данном случае type = быдлокод.

Любопытно, но зачем может понадобиться сложение классов?

А, тут вообще речь про сложение классов. Так это типичное сравнение тогда.

И чем же isinstance тут поможет?

class Core:
    def __init__(self, n):
        self.n = n


class A(Core):
    pass

class B(Core):
    pass


a = A(10)
aa = A(5)

b = B(20)
bb = B(25)

aaa = a + aa - успешно, aaa.n = 15
bbb = a + bb - TypeError

хочется как-то так ...

Ну раз хочется:

class Core(object):
	def __init__(self, n):
		self.n = n
	def __add__(self, other):
		if type(self) != type(other):
			raise TypeError("undefined addition: %s, %s" % (type(self), type(other)))
		return type(self)(self.n + other.n)
 
 
class A(Core): 
    pass 
 
class B(Core): 
    pass 
 
 
a = A(10) 
aa = A(5) 
 
b = B(20) 
bb = B(25) 
 
aaa = a + aa 
bbb = a + bb 

И еще раз: про какой питон речь?

2.5

В 2.5 иной синтаксис исключений, чем я написал:

raise TypeError, "undefined addition: %s, %s" % (type(self), type(other))

Неправда

Python 2.5.2 (r252:60911, Jan 20 2010, 23:16:55) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> raise Exception("ZHOPA")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
Exception: ZHOPA
>>> 

http://docs.python.org/release/2.5.4/tut/node10.html#raising

Alternatively, the above could be written as raise NameError('HiThere'). Either form works fine, but there seems to be a growing stylistic preference for the latter.

Тем не менее непосредственный синтаксис указан другой. Ладно, фиг с ним, с raise'ом, с except так уже не прокатит.

Меня больше интересует вопрос, чем isinstance в данном случае лучше сравнения типов? Хотя... чисто идеологически конечно же лучше, сравнение типов в наследование не укладывается, конечно.

Я склоняюсь к такому ответу:

http://stackoverflow.com/questions/1549801/differences-between-isinstance-and...

В общем, чтобы избежать проблем с наследованием как мне кажется

Вам даже официально советуют не быдлокодить: The isinstance() built-in function is recommended for testing the type of an object.

http://docs.python.org/library/functions.html#type

Если вы не понимаете почему, то учите матчасть ООП.

там не обосновывают это, без обоснования рекоммендации неинтересны. Кроме того офицальная документация не всегда права потому как устаревает и никто её не вычитывает.

Что касается питона, то тут официальная документация практически никогда не устаревает.

Чукча не читатель? Вопрос не стоял как «зачем вообще использовать isinstance?»

Перегрузка операторов вроде «+» выдает говнодизайн, говнокод и разруху в головах. Особенно в питоне.

угу, потому что я багрепорты пишу :). Серьёзно, там бывают ошибки.

Да конечно же!

grep -R "def __add__" /home && echo "kill me please"

> Перегрузка операторов вроде «+» выдает говнодизайн, говнокод и разруху в головах. Особенно в питоне.

Скажем так, захотелось мне своих п-адических чисел с блекджеком и шлюхами. Так что теперь, если определю __add__ для них, то весь код сразу станет говнокодом?

> там не обосновывают это, без обоснования рекоммендации неинтересны.

man SOLID и Liskov Substitution Principle в частности.

устаревает и никто её не вычитывает. Серьёзно, там бывают ошибки.

Пруф или не было.

> man SOLID и Liskov Substitution Principle в частности.

Опять же, паттерны проектирования. Не серебряная пуля. Хотя подход безусловно хороший и правильный.

При чём тут man solid? Я сказал что рекомендации без обоснования мало чего стоят потому что их проверить нельзя. ООП тут ни при чём.

Пруф вот(тока открытые тикеты, закрытых сильно больше, штук пять я создал когда время было):
http://bugs.python.org/issue?%40search_text=&title=&%40columns=title&id=&%40c...