Python introduceerde de abc module in versie 2.6 om Abstract Base Classes te formaliseren, waarmee structurele subtype-ing mogelijk werd buiten de traditionele duck typing. Het kernmechanisme is de __subclasshook__ klasse methode, die door de abc machine wordt aangeroepen wanneer issubclass() er niet in slaagt de kandidaat in de MRO van de ABC te vinden. Deze methode ontvangt de kandidaat klasse en retourneert True, False of NotImplemented, waardoor virtuele registratie zonder overerving mogelijk is.
Het probleem ontstaat omdat __subclasshook__ vaak moet verifiëren of de kandidaat specifieke methoden of attributen implementeert. Zonder een beschermende voorwaarde, als de haak intern issubclass() of soortgelijke controles aanroept die terugleiden naar dezelfde ABC, kan dit onbeperkte recursie veroorzaken. De verplichte beschermende maatregel vereist dat gecontroleerd wordt if cls is MyABC aan het begin van de methode, zodat de haak alleen de specifieke ABC valideert die het definieert, niet de subklassen van die ABC.
from abc import ABC, abstractmethod class Drawable(ABC): @abstractmethod def draw(self): pass @classmethod def __subclasshook__(cls, C): # Bescherm tegen recursie: behandel alleen Drawable direct if cls is not Drawable: return NotImplemented # Structurele controle: doet het wandelend en pratend als een Drawable? if hasattr(C, "draw") and callable(getattr(C, "draw")): return True return NotImplemented class Circle: def draw(self): print("Circle tekenen") # Virtuele subclass verificatie zonder overerving assert issubclass(Circle, Drawable)
Ons team bouwde een unified analytics platform dat meerdere database backends moest ondersteunen. We definieerden een DatabaseDriver ABC met methoden als connect(), execute() en close(). We wilden echter bestaande third-party database bibliotheken (zoals psycopg2 of pymongo) ondersteunen zonder deze te forkeren of in boilerplate adapterklassen te wikkelen.
De eerste oplossing die we overwogen was strikte adapter patroon overerving. We zouden wrapperklassen zoals Psycopg2Adapter(DatabaseDriver) creëren die de third-party verbindingen encapsuleerden. Dit bood perfecte typeveiligheid en ondersteuning voor statische analyse. Echter, het creëerde aanzienlijke onderhoudskosten voor elke methode delegatie en introduceerde dubbele indirectie overhead tijdens runtime.
De tweede benadering was pure duck typing met runtime-attribuutinspectie. We zouden eenvoudig aannemen dat elk object met connect en execute methoden een geldige driver was. Hoewel dit maximale flexibiliteit en nul boilerplate bood, faalde het stilletjes wanneer de methodehandtekeningen niet compatibel waren. Bovendien konden statische typecheckers zoals mypy deze contracten niet valideren, wat leidde tot vertraagde foutdetectie in productieomgevingen.
We kozen voor de derde oplossing: implementatie van __subclasshook__ in onze DatabaseDriver ABC om virtuele subklassen te registreren. Dit elimineerde de noodzaak voor wrapperklassen terwijl strikte isinstance validatie behouden bleef en third-party klassen typecontroles konden doorstaan zonder wijziging. De beschermende voorwaarde zorgde ervoor dat het controleren van een subclass van DatabaseDriver tegen zichzelf geen oneindige lussen zou veroorzaken.
Het resultaat was een vermindering van 40% in adapter boilerplate code en naadloze IDE autocompletesupport. Het systeem kon nu ruwe databaseverbindingen van bibliotheken accepteren die niets wisten over onze ABC, terwijl strikte runtime-validatie en structurele typegaranties behouden bleven.
Waarom moet __subclasshook__ if cls is MyABC controleren voordat structurele controles worden uitgevoerd, en wat gebeurt er als deze controle wordt weggelaten?
Zonder deze beveiliging, het aanroepen van issubclass(SubClass, MyABC) activeert MyABC.__subclasshook__(SubClass). Als de haak intern issubclass(SubClass, MyABC) controleert om de erfenis te verifiëren, dan creëert dit onmiddellijke oneindige recursie. Python's abc machine roept de haak alleen aan voor de exacte klasse die het definieert, maar structurele controles leiden vaak terug naar dezelfde vraag. De stack overflowt snel zonder de beveiliging om ervoor te zorgen dat de haak alleen de specifieke ABC valideert die het definieert.
Hoe verschilt virtueel subclassen via register() van __subclasshook__ qua prestaties en mutabiliteit?
register() voegt de klasse onmiddellijk toe aan een interne cache (_abc_cache), waardoor latere controles O(1) zijn via set lookup. In tegenstelling tot dat, voert __subclasshook__ arbitraire Python-code uit bij elke issubclass aanroep tenzij gecached, wat rekenkundige overhead creëert. Bovendien is register() permanent voor de levensduur van het proces en werkt het op ingebouwde types zoals list. Ondertussen stelt __subclasshook__ dynamische, voorwaardelijke logica in op basis van runtime mogelijkheden, maar werkt het alleen voor door de gebruiker gedefinieerde ABC's.
Wat is de interactie tussen __subclasshook__ en de __instancecheck__ methode in aangepaste metaclasses?
Wanneer isinstance(obj, MyABC) wordt aangeroepen, raadpleegt Python eerst de metaclass __instancecheck__ van de instantie. Als deze niet beschikbaar of niet definitief is, valt het terug op issubclass(type(obj), MyABC), wat __subclasshook__ activeert. Kandidaten missen vaak dat __subclasshook__ alleen deelneemt aan klassecontroles, niet aan directe instantiecontroles. Ze over het hoofd zien ook dat het retourneren van NotImplemented de controle door de MRO heen laat gaan, waardoor coöperatieve meerdere dispatch over complexe hiërarchieën mogelijk wordt.