Список с разными объектами

Это вопрос об isinstance или о zip?

isinstance

Оно, спасибо.

Красивее было бы:

for actn, rec in zip(lst[0::2], lst[1::2]):
  assert isinstance(act, CAction) and isinstance(rec, QSqlRecord)
  actn.exec(rec)

Как в зависимоти от объекта выполнить некоторые действия?

Позднее связывание, виртуальные методы, отправка сообщений, блаблабла.

Книжки по образцово-грамотному ООП (особенно по языкам, которые стояли у Истоков) в один голос твердят, что негоже принимать решения, основываясь на типе объекта, лучше уж попросить объект сделать что-то, а он там решит, что делать (в зависимости от своего типа, да!).

исинстанс и иже с ними - это же антипаттерн в большинстве случаев.

лучше уж попросить объект сделать что-то

Прости, чувак, пистон так не умеет.

пистон не умеет в методы?

Вот кстати в контексте множественной диспетчеризации (которая, по всей видимости, здесь фигурирует), возможно это и есть наиболее компактный (и тогда оправданный) метод записи

Пистон при вызове несуществующего метода кидает исключение. Сам объект, в отличии от того что в Smalltalk или Ruby, ничего не получит.

исинстанс и иже с ними - это же антипаттерн в большинстве случаев.

Предложи другой метод контроля.

Дабл диспатчинг.

несуществующего

Я про несуществующие ещё ничего не говорил :) Я намекал на визитор какбе

object.AcceptVisitor (myVisitor)

object.AcceptVisitor (myVisitor)

Ты серьезно?

Абсолютно идиоматические решения для рубей и прочих смолтоков, обычно рассказывается прям сразу вместе с объектной моделью.

Абсолютно идиоматические решения для рубей и прочих смолтоков

Отличное обоснование.

Вообще-то это ближе к жабке и плюсам. В рубях и смолтоках-то как раз дернуть объект на его класс проще простого.

Тут выбор - костыльный паттерн-матчинг на isinstance'ах или дабл диспатч в стиле визитора. Выбор из них исключительно вопрос вкуса.

Почти.

Я нутром чую, что

if (class-of(foo) == Foo) && class-of(bar) == Bar) then pewpewew()

- говно, но обосновать это с (прости Г-ди) академической точки зрения пока не могу. Придёт время, и, !

Тут выбор - костыльный паттерн-матчинг на isinstance'ах или дабл диспатч в стиле визитора. Выбор из низ исключительно вопрос вкуса.

Тут конкретная структура данных в программе и необозримая кодовая база. В таких условиях городить для решения локальной задачи визитор - это нужно быть перфекционистом-паттернофилом или просто поехавшим.

Я нутром чую, что

if (class-of(foo) == Foo) && class-of(bar) == Bar) then pewpewew()

А я нутром чую, что ты выдумал не относящуюся к делу куету.

красивее было бы список пар держать: [(actn0, rec0), (act1, rec1), ...]

QSqlRecord

судя по букве Q, это Qt?

CAction

судя по букве C, это... WTF o_O ?!

красивее было бы список пар держать: [(actn0, rec0), (act1, rec1), ...]

Согласен. Я и делаю список пар, проверяю, что типы объектов пары правильные, а потом использую пару.

А почему «или»? Разве это не одно и то же?

+1

Я нутром чую, что
if (class-of(foo) == Foo) && class-of(bar) == Bar) then pewpewew()
- говно

аналог этого кода на питоне будет:

if (type(foo) is Foo) and (type(bar) is Bar):

и такой код действительно считается плохим.

‘isinstance’ сработает даже если Foo будет одним из классов в цепочке наследования класса объекта ‘foo’. И, собственно, в отличие от использования type не по делу, isinstance для того и придуман.

Суть не в этом. Суть в том, что решения принимаются на основе принадлежности объекта к определенному классу (иерархии)

Суть в том, что решения принимаются на основе принадлежности объекта к определенному классу (иерархии)

И это плохо, потому что... ?

Похоже, ты просто привык к другому приготовлению ООП.

У него там QAction и QSqlRecord, какие у них могут быть общие операции? Он скорее всего ошибся уже на этапе занесения их в единый список

Потому что поведение описано не через взаимодействие объектов.

поведение описано не через взаимодействие объектов.

Как уже сказали, isinstance в моем пример не используется для описания поведения. Мммкей, попробуем по-другому: перепиши пример так, чтобы не использовать isinstance.

А для чего он используется?

Для проверки, что список состоит из пар правильного типа.

Абсолютно идиоматические решения для рубей и прочих смолтоков

В Ruby и Smalltalk можно просто к обоим классам добавить нужный метод. А использование Visitor'а в данном случае ничем не будет отличаться от isinstance, разве что этот isinstance будет спрятан в кишках Visitor'а (и, возможно, присыпан сахарком).

В смысле, подмешать к уже существующему?

Для меня подмешивание ассоциируется с миксинами и трейтами, а это немножко не то. Я имею в виду, что можно взять существующий класс, добавить к нему новый метод, и все ранее созданные объекты этого класса автоматически получат эти методы. А в Ruby с помощью refinements можно ещё и контролировать область видимости этих методов.

module MyRefinements
  refine CAction do
    def foo
      # ...
    end
  end

  refine QSqlRecord do
    def foo
      # ...
    end
  end
end

module MyCode
  using MyRefinements

  # ...
  actions_and_records.each(&:foo)
end

Вообще офигеть.

>>> class A():
...     pass
... 
>>> b = A()
>>> b.c()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: A instance has no attribute 'c'
>>> A.c = (lambda this: 100)
>>> b.c()
100

Круто, но мы вроде бы говорили про Ruby и Smalltalk (хотя про то, что Python так может, я не знал).

И это плохо, потому что... ?

Потому что, айыыы. Потому же, почему и динамик_каст в крестах часто антипаттерн, как звоночек о косяках в архитектуре.

Если честно,я не могу внятно сформулировать, почему. Но придёт время, и я это обязательно сделаю, если не превращуюсь к кулинхао

Потому что в таком случае метод взаимодействующий с объектами каких-то классов описан не в этом классе. Нарушение инкапсуляции, не работает полиморфизм.

метод взаимодействующий с объектами каких-то классов описан не в этом классе

Я до сих пор удивляюсь - где вы там увидели взаимодействие? Там проверяется контракт, не более. У вас какой-то коленный рефлекс на isinstance.

Принадлежность к классу не может быть контрактом, это нарушение инкапсуляции.

Принадлежность к классу не может быть контрактом

Может и является.

это нарушение инкапсуляции.

Нет.

И это плохо, потому что... ?

Например. У тебя есть класс A, у него некий признак a. Есть у него наследний B, который тоже обладает признаком a. Ты решил сделать проверку наличия признака a через isinstance A. А потом у класса B появляется наследник C, которому надо этот признак убрать (ну вот такой частный случай, ага). В обычном ООП ты бы изначально использовал метод hasMark(a) и переопределил его где надо. А здесь как поступишь?

Ты решил сделать проверку наличия признака a через isinstance A

Зачем я так сделал?

В обычном ООП ты бы изначально использовал метод hasMark(a). А здесь как поступишь?

Если задача в том, чтобы проверить наличие атрибута «a», она решается hasattr. Если задача в чем-то другом - сформулируй ее.

Если ты делаешь isinstance, значит ты проверяешь некое условие. Ему отвечают объекты неких классов. Это я и назвал признаком a.

потом у класса B появляется наследник C, которому надо этот признак убрать

В стандартную библиотеку батареек питона кстати такое не принимают.

В стандартную библиотеку могут принимать или не принимать что угодно, но по факту такие ситуации бывают. Я не так давно писал код, гда у класса метод возвращает true, а у некоторых его детей false. И вполне возможно, что у кого-то из детей их детей в будущем может переопределяться обратно в true.