Краткий ответ

Проверка через isinstance учитывает наследование: объект подкласса считается экземпляром его базового класса. Проверка через type(obj) is SomeClass требует, чтобы фактический тип объекта был ровно SomeClass, без подклассов.

Исторический контекст

Подход с isinstance нужен для работы с объектами через общий интерфейс базового класса. Он поддерживает полиморфизм: функция может принимать экземпляры разных подклассов, если они относятся к одной иерархии.

Точная проверка типа решает другую задачу — ограничивает алгоритм конкретной реализацией. Поэтому это не взаимозаменяемые проверки: выбор зависит от того, важна ли совместимость поведения или точная разновидность объекта.

Постановка проблемы

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

Обратная ошибка тоже опасна. isinstance может пропустить подкласс, который формально относится к нужной иерархии, но меняет поведение, критичное для конкретного алгоритма.

Подробное решение

isinstance(obj, BaseClass) возвращает истину, если объект является экземпляром BaseClass или любого его подкласса. Это проверка принадлежности к типовой иерархии, а не сравнение только с непосредственным классом.

Для проверки ровно заданного класса используют сравнение объекта типа с ожидаемым классом: type(obj) is BaseClass. У подкласса type(obj) будет равен самому подклассу, поэтому такая проверка вернёт ложь.

class Animal:
    pass

class Dog(Animal):
    pass

pet = Dog()
print(isinstance(pet, Animal))  # True
print(type(pet) is Animal)      # False
print(type(pet) is Dog)         # True

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

Проверка isinstance также может учитывать абстрактные базовые классы и пользовательскую логику проверки экземпляра. Поэтому она не всегда означает наличие прямой записи класса в цепочке наследования.

Ситуация из практики

В системе обработки событий есть базовый класс события и несколько специализированных подклассов. Обработчик должен принимать любое событие этой иерархии и извлекать общий идентификатор.

Вариант с точной проверкой типа прост для чтения, но отклонит новые подклассы и нарушит расширяемость. Вариант с isinstance принимает базовый класс и его подклассы, поэтому лучше соответствует общему контракту.

Можно также проверять наличие нужного метода, следуя утиной типизации. Это гибче и допускает независимые классы, но требует определить, какие методы и гарантии действительно обязательны; для формальной иерархии событий isinstance обычно понятнее.

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

Что кандидаты часто упускают

Будет ли isinstance истинным для экземпляра подкласса?

Да. Если Dog наследуется от Animal, экземпляр Dog является экземпляром Animal с точки зрения isinstance. Это и позволяет передавать специализированные объекты функциям, ожидающим базовый тип.

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

Да. Для некоторых абстрактных базовых классов возможна регистрация виртуального подкласса, а метакласс может переопределить логику проверки через __instancecheck__. Поэтому isinstance следует воспринимать как проверку соответствия принятому типом критерию экземпляра, а не только как механический обход __bases__.

Почему точная проверка типа часто считается признаком хрупкого дизайна?

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