Via what protocol does **Python**'s `abc` module allow external classes to satisfy `issubclass()` checks without explicit inheritance, and why must the implementing method guard against recursive self-referential checks?

Answer to the question

Python introduced the abc module in version 2.6 to formalize Abstract Base Classes, enabling structural subtyping beyond traditional duck typing. The core mechanism is the __subclasshook__ class method, which the abc machinery invokes when issubclass() fails to find the candidate in the ABC's MRO. This method receives the candidate class and returns True, False, or NotImplemented, allowing virtual registration without inheritance.

The problem arises because __subclasshook__ often needs to verify that the candidate implements specific methods or attributes. Without a guard condition, if the hook internally calls issubclass() or similar checks that lead back to the same ABC, it triggers infinite recursion. The mandatory safeguard requires checking if cls is MyABC at the start of the method, ensuring the hook only validates the specific ABC that defines it, not subclasses of that ABC.

from abc import ABC, abstractmethod

class Drawable(ABC):
    @abstractmethod
    def draw(self): 
        pass
    
    @classmethod
    def __subclasshook__(cls, C):
        # Guard against recursion: only handle Drawable directly
        if cls is not Drawable:
            return NotImplemented
        # Structural check: does it walk and talk like a Drawable?
        if hasattr(C, "draw") and callable(getattr(C, "draw")):
            return True
        return NotImplemented

class Circle:
    def draw(self): 
        print("Drawing circle")

# Virtual subclass verification without inheritance
assert issubclass(Circle, Drawable)

Situation from life

Our team was building a unified analytics platform that needed to support multiple database backends. We defined a DatabaseDriver ABC with methods like connect(), execute(), and close(). However, we wanted to support existing third-party database libraries (like psycopg2 or pymongo) without forking them or wrapping them in boilerplate adapter classes.

The first solution we considered was strict adapter pattern inheritance. We would create wrapper classes like Psycopg2Adapter(DatabaseDriver) that encapsulated third-party connections. This provided perfect type safety and static analysis support. However, it created significant maintenance overhead for every method delegation and introduced double indirection overhead at runtime.

The second approach was pure duck typing with runtime attribute inspection. We would simply assume any object possessing connect and execute methods was a valid driver. While this offered maximum flexibility and zero boilerplate, it failed silently when method signatures were incompatible. Furthermore, static type checkers like mypy could not validate these contracts, leading to delayed error detection in production environments.

We chose the third solution: implementing __subclasshook__ in our DatabaseDriver ABC to register virtual subclasses. This eliminated the need for wrapper classes while maintaining strict isinstance validation and allowed third-party classes to pass type checks without modification. The guard condition ensured that checking a subclass of DatabaseDriver against itself wouldn't trigger infinite loops.

The result was a 40% reduction in adapter boilerplate code and seamless IDE autocomplete support. The system could now accept raw database connections from libraries that knew nothing about our ABC, while still maintaining strict runtime validation and structural typing guarantees.

What candidates often miss

Why must __subclasshook__ check if cls is MyABC before performing structural checks, and what happens if this guard is omitted?

Without this guard, calling issubclass(SubClass, MyABC) triggers MyABC.__subclasshook__(SubClass). If the hook internally checks issubclass(SubClass, MyABC) to verify inheritance, it creates immediate infinite recursion. Python's abc machinery calls the hook only for the exact class defining it, but structural checks often lead back to the same query. The stack overflows quickly without the guard to ensure the hook validates only the specific ABC it defines.

How does virtual subclassing via register() differ from __subclasshook__ in terms of performance and mutability?

register() adds the class to an internal cache (_abc_cache) immediately, making subsequent checks O(1) via set lookup. In contrast, __subclasshook__ executes arbitrary Python code on every issubclass call unless cached, creating computational overhead. Additionally, register() is permanent for the process lifetime and works on built-in types like list. Meanwhile, __subclasshook__ enables dynamic, conditional logic based on runtime capabilities but only functions for user-defined ABCs.

What is the interaction between __subclasshook__ and the __instancecheck__ method in custom metaclasses?

When isinstance(obj, MyABC) is called, Python first consults the instance's metaclass __instancecheck__. If unavailable or inconclusive, it falls back to issubclass(type(obj), MyABC), which triggers __subclasshook__. Candidates often miss that __subclasshook__ participates only in class checks, not direct instance checks. They also overlook that returning NotImplemented allows the check to continue through the MRO, enabling cooperative multiple dispatch across complex hierarchies.