Storia della domanda
Il protocollo __mro_entries__ è stato introdotto in Python 3.7 tramite PEP 560 ("Supporto fondamentale per il modulo typing e tipi generici"). Prima di questo miglioramento, alias generici come typing.List[int] non potevano essere utilizzati come classi base nelle definizioni di classi perché type.__new__ richiedeva severamente che tutte le classi base fossero istanze di type. Questa limitazione costringeva il modulo typing a fare affidamento su fragili hack di metaclassi che erano difficili da mantenere e causavano problemi di prestazioni. Il protocollo è stato progettato per disaccoppiare l'espressione sintetica di una base dal suo contributo semantico al grafo di ereditarietà, consentendo un supporto più pulito per generici e pattern di fabbrica.
Il problema
Quando CPython elabora una definizione di classe, deve calcolare l'Ordine di Risoluzione dei Metodi (MRO) utilizzando l'algoritmo di linearizzazione C3 per garantire una gerarchia di ricerca dei metodi coerente e prevedibile. Se un oggetto base non è una classe (ad esempio, un generico parametrizzato o un oggetto di configurazione), l'interprete non ha le informazioni di tipo necessarie per posizionare correttamente la nuova classe all'interno dell'albero di ereditarietà. Semplicemente ignorare tali oggetti romperebbe i controlli isinstance e le catene di super(), mentre rifiutarli completamente impedirebbe potenti pattern di metaprogrammazione. La sfida principale era consentire a questi oggetti non classi di dichiarare quali classi concrete rappresentano logicamente durante la fase di costruzione della classe.
La soluzione
Python ora ispeziona ogni elemento nella tupla delle basi per un metodo __mro_entries__(self, bases) durante la creazione della classe. Se questo metodo esiste, viene invocato con la tupla delle basi originale e deve restituire una tupla di classi effettive da sostituire per l'oggetto nel calcolo della MRO. Le classi restituite vengono quindi trattate come se fossero state esplicitamente elencate come basi. Questo meccanismo consente a un'istanza di fungere da segnaposto trasparente che si risolve in classi concrete al momento della definizione.
class ConfigurableMixin: def __init__(self, feature): self.feature = feature def __mro_entries__(self, bases): # Inietta dinamicamente classi base in base alla configurazione if self.feature == "logging": return (LoggingSupport,) return (BaseFeature,) class LoggingSupport: def log(self, msg): print(msg) class BaseFeature: pass # L'istanza viene sostituita da LoggingSupport nel MRO class Service(ConfigurableMixin("logging")): pass print(LoggingSupport in Service.__mro__) # True
In un ampio framework web asincrono, gli sviluppatori avevano bisogno di creare una fabbrica DatabaseMixin che, quando istanziata con un URL di database specifico (ad esempio, DatabaseMixin("postgresql://")), inietterebbe automaticamente sia ConnectionPool che AsyncSession come classi base nella classe di servizio dell'utente. La difficoltà era che DatabaseMixin(...) restituiva un'istanza oggetto semplice, non una classe, eppure doveva partecipare nel MRO come se lo sviluppatore avesse esplicitamente scritto class UserService(ConnectionPool, AsyncSession).
Soluzione 1: Metaclass personalizzata
Un approccio prevedeva la creazione di una metaclass che esaminava la tupla bases in __new__, identificava le istanze di DatabaseMixin e le sostituiva con le classi target prima di chiamare super().__new__. Questo consentiva un controllo preciso ma introduceva il problema del "conflitto di metaclassi": qualsiasi servizio che utilizzava questa metaclass non poteva ereditare da altre classi che definivano proprie metaclassi, come alcune classi base di ORM. Inoltre, il debugging diventava difficile perché la sintassi della definizione della classe nascondeva trasformazioni complesse e gli stack trace puntavano agli interni delle metaclassi piuttosto che al codice dell'utente.
Soluzione 2: Decorazione della Classe Post-Creazione
Un'altra opzione era utilizzare un decoratore di classe applicato dopo che la classe era stata creata. Il decoratore avrebbe copiato manualmente i metodi da ConnectionPool e AsyncSession sulla nuova classe oppure utilizzava type.__setattr__ per iniettarli. Sebbene questo evitasse la viralità delle metaclassi, rompeva fondamentalmente il modello di ereditarietà di Python: isinstance(UserService(), ConnectionPool) avrebbe restituito False, e le chiamate super() all'interno dei metodi copiati si sarebbero risolte in modo errato poiché il MRO non conteneva effettivamente le classi genitore. Questo portava a bug sottili in cui le utility del framework non riconoscevano i servizi come capaci di database.
Soluzione 3: Protocollo __mro_entries__
Il team ha scelto di implementare __mro_entries__ sull'oggetto restituito da DatabaseMixin. Il metodo restituiva (ConnectionPool, AsyncSession) in base all'URL analizzato. Questa soluzione si integrava senza problemi con il meccanismo nativo di creazione delle classi di CPython. Il MRO veniva calcolato correttamente, i controlli isinstance funzionavano naturalmente e non c'erano conflitti di metaclassi. L'istanza della fabbrica agiva come un segnaposto dichiarativo che si dissolveva nella corretta struttura di ereditarietà durante la costruzione della classe, preservando la semantica di super() e la compatibilità con l'ereditarietà multipla.
Il risultato era un'API pulita e intuitiva in cui gli sviluppatori potevano scrivere class OrderService(DatabaseMixin(postgres_url)): e ricevere automaticamente capacità di pooling delle connessioni e gestione delle sessioni con una corretta risoluzione dei metodi, pieno supporto IDE e zero overhead o conflitti di ereditarietà a runtime.
Come gestisce la linearizzazione C3 i potenziali duplicati quando __mro_entries__ espande una base in classi già presenti altrove nell'elenco di ereditarietà?
Quando __mro_entries__ restituisce una classe che appare anche altrove nelle basi (ad esempio, se una fabbrica si espande in (BaseA,) e un'altra base esplicita è Derived(BaseA)), l'algoritmo C3 di Python tratta la tupla espansa come l'elenco delle basi effettivo. L'algoritmo quindi unisce queste liste preservando l'ordine di precedenza locale e assicurando la monotonicità. Poiché C3 è progettato per gestire antenati comuni, BaseA appare solo una volta nel MRO finale, posizionato dopo tutte le classi che dipendono da essa ma prima di object. I candidati spesso credono erroneamente che questo crei un conflitto o un'entrata duplicata, ma il processo di linearizzazione elimina naturalmente i duplicati mantenendo il vincolo "bambini prima dei genitori", garantendo una risoluzione coerente dei metodi.
Perché __mro_entries__ non può accedere alla classe in fase di creazione, e quale specifico errore si verifica se tenta di farlo?
Durante la creazione della classe, type.__new__ chiama __mro_entries__ sugli oggetti base prima che l'oggetto di classe sia stesso istanziato. Il dizionario del namespace esiste, ma l'oggetto di classe non ha ancora un'identità. Se l'implementazione tenta di accedere agli attributi della classe prospettica (ad esempio, facendo riferimento al nome della classe da uno scope esterno o tentando di ispezionare bases come se fossero già legati alla nuova classe), solleverà un NameError o un AttributeError perché il binding non esiste ancora. I candidati spesso assumono di poter ispezionare lo stato finale della classe o __dict__ per prendere decisioni dinamiche, ma il metodo riceve solo la tupla delle basi originali come argomento e deve fare affidamento sul proprio stato interno per determinare il valore di ritorno.
Registrare un oggetto con __mro_entries__ come sottoclasse virtuale di un ABC tramite abc.ABCMeta.register() fa sì che l'ABC appaia nel MRO?
No. La registrazione di sottoclassi virtuali è un meccanismo di runtime che popola una cache interna all'interno dell'ABC per i controlli isinstance() e issubclass(). Non altera l'attributo __mro__ della sottoclasse. Quando viene definita MyClass(MyObject()) e MyObject() restituisce (ConcreteBase,) tramite __mro_entries__, solo ConcreteBase appare in MyClass.__mro__. Se ConcreteBase è registrato come sottoclasse virtuale di MyABC, allora isinstance(MyClass(), MyABC) restituisce True, ma MyABC non sarà presente in MyClass.__mro__. I candidati spesso confondono il sottoclassing virtuale con la vera ereditarietà, portando a confusione su perché le chiamate super() o l'ispezione del MRO non riflettano la relazione ABC, o perché i metodi definiti sull'ABC non siano disponibili tramite ereditarietà.