Python a introduit le module abc dans la version 2.6 pour formaliser les classes de base abstraites, permettant le sous-typage structurel au-delà du typage par canard traditionnel. Le mécanisme central est la méthode de classe __subclasshook__, qui est appelée par la machine abc lorsque issubclass() ne trouve pas le candidat dans l'ordre des classes de la classe de base (MRO) de l'ABC. Cette méthode reçoit la classe candidat et renvoie True, False ou NotImplemented, permettant un enregistrement virtuel sans héritage.
Le problème se pose car __subclasshook__ doit souvent vérifier que le candidat implémente des méthodes ou attributs spécifiques. Sans une condition de garde, si le hook appelle en interne issubclass() ou des vérifications similaires qui renvoient à la même ABC, cela déclenche une récursion infinie. La garde obligatoire nécessite de vérifier if cls is MyABC au début de la méthode, s'assurant que le hook ne valide que l'ABC spécifique qui le définit, et non les sous-classes de cet 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 # Vérification structurelle: est-ce que ça marche et parle comme un Drawable ? if hasattr(C, "draw") and callable(getattr(C, "draw")): return True return NotImplemented class Circle: def draw(self): print("Dessin du cercle") # Vérification de sous-classe virtuelle sans héritage assert issubclass(Circle, Drawable)
Notre équipe construisait une plateforme d'analytique unifiée qui devait supporter plusieurs backends de bases de données. Nous avons défini une ABC DatabaseDriver avec des méthodes comme connect(), execute() et close(). Cependant, nous voulions prendre en charge les bibliothèques de bases de données tierces existantes (comme psycopg2 ou pymongo) sans les forker ou les envelopper dans des classes d'adaptateur de code répétitif.
La première solution que nous avons envisagée était l'héritage strict du modèle d'adaptateur. Nous aurions créé des classes d'enveloppement comme Psycopg2Adapter(DatabaseDriver) qui encapsulaient les connexions tierces. Cela offrait une sécurité de type parfaite et un support d'analyse statique. Cependant, cela créait une charge de maintenance significative pour chaque délégation de méthode et introduisait une surcharge d'indirection double au moment de l'exécution.
La deuxième approche était le typage par canard pur avec inspection d'attributs à l'exécution. Nous nous serions simplement fiés à toute objet possédant des méthodes connect et execute comme un driver valide. Bien que cela offrait une flexibilité maximale et zéro code répétitif, cela échouait silencieusement lorsque les signatures des méthodes étaient incompatibles. De plus, les vérificateurs de type statiques comme mypy ne pouvaient pas valider ces contrats, entraînant un retard dans la détection des erreurs dans les environnements de production.
Nous avons choisi la troisième solution : implémenter __subclasshook__ dans notre ABC DatabaseDriver pour enregistrer des sous-classes virtuelles. Cela a éliminé le besoin de classes d'enveloppement tout en maintenant une validation stricte isinstance et a permis aux classes tierces de passer les contrôles de type sans modification. La condition de garde garantissait que vérifier une sous-classe de DatabaseDriver contre elle-même ne déclenche pas de boucles infinies.
Le résultat a été une réduction de 40 % du code d'adaptateur répétitif et un support complet de l'autocomplétion IDE. Le système pouvait désormais accepter des connexions de base de données brutes provenant de bibliothèques qui ne savaient rien de notre ABC, tout en maintenant des validations d'exécution strictes et des garanties de typage structurel.
Pourquoi __subclasshook__ doit-il vérifier if cls is MyABC avant d'effectuer des vérifications structurelles, et que se passe-t-il si cette garde est omise ?
Sans cette garde, appeler issubclass(SubClass, MyABC) déclenche MyABC.__subclasshook__(SubClass). Si le hook vérifie en interne issubclass(SubClass, MyABC) pour confirmer l'héritage, cela crée immédiatement une récursion infinie. La machine abc de Python appelle le hook uniquement pour la classe exacte qui le définit, mais les vérifications structurelles retournent souvent à la même requête. La pile dépasse rapidement sans la garde pour s'assurer que le hook valide uniquement l'ABC spécifique qu'il définit.
Comment le sous-typage virtuel via register() diffère-t-il de __subclasshook__ en termes de performance et de mutabilité ?
register() ajoute la classe à un cache interne (_abc_cache) immédiatement, rendant les vérifications ultérieures O(1) via une recherche dans un ensemble. En revanche, __subclasshook__ exécute un code Python arbitraire à chaque appel issubclass sauf s'il est mis en cache, créant une surcharge computationnelle. De plus, register() est permanent pour la durée du processus et fonctionne sur des types intégrés comme list. Pendant ce temps, __subclasshook__ permet une logique conditionnelle dynamique basée sur les capacités à l'exécution mais ne fonctionne que pour les ABC définis par l'utilisateur.
Quelle est l'interaction entre __subclasshook__ et la méthode __instancecheck__ dans les méta-classes personnalisées ?
Lorsque isinstance(obj, MyABC) est appelé, Python consulte d'abord la méthode __instancecheck__ de la méta-classe de l'instance. Si celle-ci n'est pas disponible ou peu concluante, elle retombe sur issubclass(type(obj), MyABC), ce qui déclenche __subclasshook__. Les candidats négligent souvent que __subclasshook__ participe uniquement aux vérifications de classe, pas aux vérifications d'instance directes. Ils oublient également que renvoyer NotImplemented permet à la vérification de continuer à travers le MRO, permettant une dispatching multiple coopérative à travers des hiérarchies complexes.