Python представил модуль abc в версии 2.6, чтобы формализовать абстрактные базовые классы, позволяя структурный подтипинг помимо традиционного утиного типинга. Основным механизмом является метод класса __subclasshook__, который вызывается механизмом abc, когда issubclass() не находит кандидата в MRO ABC. Этот метод принимает кандидатский класс и возвращает True, False или NotImplemented, что позволяет виртуальную регистрацию без наследования.
Проблема возникает, потому что __subclasshook__ часто необходимо подтвердить, что кандидат реализует определенные методы или атрибуты. Без условия защиты, если хук внутренне вызывает issubclass() или аналогичные проверки, которые ведут обратно к тому же ABC, это вызывает бесконечную рекурсию. Обязательная защита требует проверки if cls is MyABC в начале метода, что гарантирует, что хук проверяет только конкретный ABC, который его определяет, а не подклассы этого ABC.
from abc import ABC, abstractmethod class Drawable(ABC): @abstractmethod def draw(self): pass @classmethod def __subclasshook__(cls, C): # Защита от рекурсии: обрабатывать только Drawable напрямую if cls is not Drawable: return NotImplemented # Структурная проверка: ведет ли себя и говорит ли, как Drawable? if hasattr(C, "draw") and callable(getattr(C, "draw")): return True return NotImplemented class Circle: def draw(self): print("Рисование круга") # Виртуальная проверка подкласса без наследования assert issubclass(Circle, Drawable)
Наша команда разрабатывала унифицированную аналитическую платформу, которая должна была поддерживать несколько баз данных. Мы определили ABC DatabaseDriver с такими методами, как connect(), execute() и close(). Однако мы хотели поддерживать существующие сторонние библиотеки базы данных (например, psycopg2 или pymongo) без их модификации или обертывания в классы адаптеров.
Первое решение, которое мы рассмотрели, состояло в строгом наследовании паттерна адаптера. Мы создали бы классы-обертки, такие как Psycopg2Adapter(DatabaseDriver), которые инкапсулировали сторонние соединения. Это обеспечивало идеальную безопасность типов и поддержку статического анализа. Однако это создавало значительные затраты на обслуживание для каждой делегации метода и вводило двойную индирекцию в время выполнения.
Второй подход заключался в чистом утином типировании с инспекцией атрибутов во время выполнения. Мы бы просто считали, что любой объект, обладающий методами connect и execute, является действительным драйвером. Хотя это обеспечивало максимальную гибкость и ноль оберток, оно тихо сбивало с толку, когда подписи методов были несовместимы. Более того, статические проверщики типов, такие как mypy, не могли проверить эти контракты, что приводило к задержке обнаружения ошибок в производственных средах.
Мы выбрали третье решение: реализовали __subclasshook__ в нашем ABC DatabaseDriver, чтобы регистрировать виртуальные подклассы. Это избавило от необходимости в классах-обертках, сохранив строгую валидацию isinstance и позволяя сторонним классам проходить проверки типов без модификаций. Условие защиты обеспечивало, что проверка подкласса DatabaseDriver против самого себя не вызовет бесконечных циклов.
Результатом стало снижение на 40% кода адаптера и безупречная поддержка автозаполнения в IDE. Теперь система могла принимать сырые соединения с базами данных из библиотек, которые ничего не знали о нашем ABC, при этом сохраняя строгую проверку во время выполнения и гарантии структурного типирования.
Почему необходимо, чтобы __subclasshook__ проверял if cls is MyABC перед выполнением структурных проверок, и что происходит, если эта защита опущена?
Без этой защиты вызов issubclass(SubClass, MyABC) вызывает MyABC.__subclasshook__(SubClass). Если хук внутренне проверяет issubclass(SubClass, MyABC) для проверки наследования, это создаёт немедленную бесконечную рекурсию. Механизм abc Python вызывает хук только для точного класса, который его определяет, но структурные проверки часто ведут обратно к тому же запросу. Стек быстро переполняется без защиты, чтобы гарантировать, что хук проверяет только конкретный ABC, который он определяет.
Как виртуальное наследование через register() отличается от __subclasshook__ с точки зрения производительности и изменяемости?
register() добавляет класс во внутренний кэш (_abc_cache) немедленно, что делает последующие проверки O(1) через поиск в множестве. В отличие от этого, __subclasshook__ выполняет произвольный код Python при каждом вызове issubclass, если его не закешировать, создавая вычислительные накладные расходы. Кроме того, register() является постоянным на весь срок службы процесса и работает на встроенных типах, таких как list. Между тем, __subclasshook__ позволяет динамическую, условную логику на основе возможностей во время выполнения, но функционирует только для пользовательских ABC.
Каково взаимодействие между __subclasshook__ и методом __instancecheck__ в пользовательских метаклассах?
Когда вызывается isinstance(obj, MyABC), Python сначала обращается к метаклассу экземпляра __instancecheck__. Если это недоступно или неясно, он возвращается к issubclass(type(obj), MyABC), что вызывает __subclasshook__. Кандидаты часто упускают, что __subclasshook__ участвует только в проверках классов, а не в прямых проверках экземпляров. Они также упускают из виду, что возврат NotImplemented позволяет проверке продолжаться через MRO, позволяя кооперативную множественную диспетчеризацию через сложные иерархии.