Python ha introdotto il modulo abc nella versione 2.6 per formalizzare le Classi Base Abstracte, permettendo il sottotipizzazione strutturale oltre il tradizionale duck typing. Il meccanismo centrale è il metodo di classe __subclasshook__, che il meccanismo di abc invoca quando issubclass() non riesce a trovare il candidato nella MRO dell'ABC. Questo metodo riceve la classe candidata e restituisce True, False o NotImplemented, consentendo la registrazione virtuale senza eredità.
Il problema sorge perché __subclasshook__ deve spesso verificare che il candidato implementi metodi o attributi specifici. Senza una condizione di guardia, se il gancio chiama internamente issubclass() o controlli simili che ritornano alla stessa ABC, si attiva una ricorsione infinita. La guardia obbligatoria richiede di controllare if cls is MyABC all'inizio del metodo, garantendo che il gancio convalidi solo la specifica ABC che la definisce, non le sottoclassi di quella ABC.
from abc import ABC, abstractmethod class Drawable(ABC): @abstractmethod def draw(self): pass @classmethod def __subclasshook__(cls, C): # Guardarsi dalla ricorsione: gestire solo direttamente Drawable if cls is not Drawable: return NotImplemented # Controllo strutturale: cammina e parla come un Drawable? if hasattr(C, "draw") and callable(getattr(C, "draw")): return True return NotImplemented class Circle: def draw(self): print("Disegnando cerchio") # Verifica della sottoclasse virtuale senza eredità assert issubclass(Circle, Drawable)
Il nostro team stava costruendo una piattaforma di analisi unificata che doveva supportare più backend di database. Abbiamo definito un ABC DatabaseDriver con metodi come connect(), execute(), e close(). Tuttavia, volevamo supportare le librerie di database di terze parti esistenti (come psycopg2 o pymongo) senza modificarle o racchiuderle in classi adattatore di boilerplate.
La prima soluzione che abbiamo considerato è stata l'ereditarietà stretta del pattern adapter. Avremmo creato classi wrapper come Psycopg2Adapter(DatabaseDriver) che incapsulavano connessioni di terze parti. Questo forniva una perfetta sicurezza di tipo e supporto per l'analisi statica. Tuttavia, creava un significativo sovraccarico di manutenzione per ogni delega di metodo e introdusse un sovraccarico di doppia indirection a tempo di esecuzione.
Il secondo approccio è stato il puro duck typing con ispezione degli attributi a tempo di esecuzione. Avremmo semplicemente supposto che qualsiasi oggetto possedente metodi connect ed execute fosse un driver valido. Anche se questo offriva la massima flessibilità e zero boilerplate, falliva silenziosamente quando le firme dei metodi erano incompatibili. Inoltre, i controllori di tipo statico come mypy non potevano convalidare questi contratti, portando a un rilevamento degli errori ritardato negli ambienti di produzione.
Abbiamo scelto la terza soluzione: implementare __subclasshook__ nel nostro ABC DatabaseDriver per registrare sottoclassi virtuali. Questo ha eliminato la necessità di classi wrapper mantenendo la rigorosa convalida isinstance e consentendo a classi di terze parti di superare i controlli di tipo senza modifica. La condizione di guardia garantiva che il controllo di una sottoclasse di DatabaseDriver contro se stessa non attivasse loop infiniti.
Il risultato è stata una riduzione del 40% del codice di boilerplate degli adapter e un supporto di completamento automatico IDE senza soluzione di continuità. Il sistema ora poteva accettare connessioni di database raw da librerie che non sapevano nulla del nostro ABC, mantenendo comunque rigorosi controlli di convalida a tempo di esecuzione e garanzie di tipizzazione strutturale.
Perché __subclasshook__ deve controllare if cls is MyABC prima di eseguire controlli strutturali, e cosa succede se questa guardia è omessa?
Senza questa guardia, chiamare issubclass(SubClass, MyABC) attiva MyABC.__subclasshook__(SubClass). Se il gancio controlla internamente issubclass(SubClass, MyABC) per verificare l'ereditarietà, crea una ricorsione infinita immediata. Il meccanismo abc di Python chiama il gancio solo per la classe esatta che lo definisce, ma i controlli strutturali spesso ritornano allo stesso interrogativo. Lo stack sovraccarica rapidamente senza la guardia per garantire che il gancio convalidi solo la specifica ABC che definisce.
Come differisce il sottotipizzazione virtuale tramite register() da __subclasshook__ in termini di prestazioni e mutabilità?
register() aggiunge la classe a una cache interna (_abc_cache) immediatamente, rendendo i controlli successivi O(1) tramite ricerca nel set. Al contrario, __subclasshook__ esegue codice Python arbitrario su ogni chiamata issubclass a meno che non venga memorizzato, creando sovraccarico computazionale. Inoltre, register() è permanente per la durata del processo e funziona su tipi incorporati come list. Nel frattempo, __subclasshook__ consente una logica dinamica e condizionale basata sulle capacità a tempo di esecuzione, ma funziona solo per ABC definiti dall'utente.
Qual è l'interazione tra __subclasshook__ e il metodo __instancecheck__ nelle metaclassi personalizzate?
Quando viene chiamato isinstance(obj, MyABC), Python consulta prima il metodo __instancecheck__ della metaclasse dell'istanza. Se non disponibile o inconcludente, torna a issubclass(type(obj), MyABC), che attiva __subclasshook__. I candidati spesso trascurano che __subclasshook__ partecipa solo nei controlli di classe, non nei controlli diretti delle istanze. Trascurano anche che restituire NotImplemented consente al controllo di continuare attraverso la MRO, abilitando un dispatch multiplo cooperativo su gerarchie complesse.