doza_and

ту дело даже не в требовании TUserList от TUser а глевное чтоб при использовании класса, в TUserList не попал никто другой кроме TUser. Потому что если попадёи, то выяснится это может очень и очень не скоро. А так выяснится при попадании.
К слову простите, вышеуказаный пример писал от руки, забыл про self.list_. Всегда забываю про селфы.

Александр Кошелев

class Userlist(object):
   def __init__(self):
      self.list_=[]
   def add(self, user):
      self.list_.add(user)

в подобный контейнер можно запихнуть всё что угодно, и он слова не скажет. А выяснится что там лежит что-то не то может уже очень и очень позно, а может и вообще не выяснится. Это затрудняет краш тесты и дебаг.

doza_and
http://hlabs.spb.ru/development/zope/in … ption.html

Это очень интересно, спасибо за информацию, изучаю. К сожалению изза специфики задачи, реализую свой контейнер обьектов, может перепишу ввиду недавнего узнавания про property в питоне. http://python.su/forum/viewtopic.php?id=12246

Alex_Kutsan
не в требовании TUserList от TUser а глевное чтоб при использовании класса, в TUserList не попал никто другой кроме TUser.

Так я про это и написал. Надо дать определение кто такой User. Допустим, что вы копите User чтобы принимать от них заказы на поставку яблок. У них тогда есть перечень заказов (количество и дата поставки) и расчетный счет. Очевидно также есть фамилия и адрес. Вы поставляете им яблоки и на новый год шлете рождественские открытки. Пока все ок?

А теперь через 3 года эксплуатации системы оказывается что у вас появились оптовые потребители - детские сады. - У них есть все - но нет фамилии (и в общем случае домашнего адреса). Поэтому под новый год ваше ПО рухнет если у детсада будет базовый класс User, а если не будет - то вы его не сможете добавить в свой список. Тут User может поддерживать две функции - обработка заказа и рождественское поздравление. И проверять надо не тип объекта, а поддержку соотв интерфейса. А эту проверку можно делать по разному. Можно описать интерфейсы - они автоматизируют хаотическую проверку (не родственных классов), можно сделать 2 базовых класса заказабельный пользователь и поздравлябельный и от них наследоваться. Тогда при проверке интерфейса можно использовать isinstance. Этот способ хорошо подходит для языков со строгой типизацией. И наконец, если поздравление второстепенная функция, которая требует только фамилии и адреса, можно при поздравлении просто проверить наличие этих полей и не усложнять остальную систему классов или интерфейсов.

Alex_Kutsan
в подобный контейнер можно запихнуть всё что угодно, и он слова не скажет. А выяснится что там лежит что-то не то может уже очень и очень позно, а может и вообще не выяснится.

Если второй вариант случится, то это вообще тогда не проблема и вы делаете лишнюю работу, проверяя тип.

А первый тоже надуманный. Я могу отнаследоваться от TUser и перекрыть как угодно его методы. И эта ваша проверка тоже окажется бесполезной, т.к. когда это объект вы будете использовать код тоже сломается.

В этом куске кода у объекта user один контракт – возможность положить его в список. И всё. Этому контракту удовлетворяет любой объект. И не надо городить лишние проверки.

Пишите код так, чтобы вам было всё равно какого типа объект, а было важно какими свойствами он обладает.

Параноидально проверять в питоне типы данных это просто глупо.

Александр Кошелев
это просто глупо

Ну почему. Если все разработчики договорятся что они не будут удалять поля и методы из объектов, то тогда это будет достаточно быстрый способ проверки интерфейса (Для больших коллективов это конечно труднодостижимо). Для полноты надо конечно сравнить сколько весит isinstance по сравнению с hasattr. Вы не знаете сколько?
Но конечно вы правы - надо рассчитывать что используются любые объекты.

doza_and
Ну почему. Если все разработчики договорятся что они не будут удалять поля и методы из объектов, то тогда это будет достаточно быстрый способ проверки интерфейса

В том и дело, что это не проверка интерфейса, а строгая проверка типа. Я могу иметь класс с таким же интерфейсом, но в параллельной иерархии.

doza_and
Для больших коллективов это конечно труднодостижимо

Так же для коллектива можно договориться использовать функционал по назначению, а не пробовать его “на зуб”, бездумно кладя в контейнер то чего в нем не должно быть.

doza_and
Для полноты надо конечно сравнить сколько весит isinstance по сравнению с hasattr

Это последнее о чем нужно думать.