Il metodo __prepare__ è stato introdotto in Python 3.0 tramite PEP 3115 per affrontare limitazioni fondamentali nel protocollo di creazione delle classi. Prima di questo cambiamento, lo spazio dei nomi utilizzato durante l'esecuzione del corpo della classe era sempre un dizionario standard, che non offriva alcun modo per preservare l'ordine di dichiarazione degli attributi o interceptare le assegnazioni mentre avvenivano. Questo è diventato particolarmente problematico per gli sviluppatori che costruivano ORM e librerie di serializzazione che dovevano tracciare la sequenza delle dichiarazioni dei campi senza ricorrere a fragili analisi del codice sorgente.
Quando Python esegue un corpo di classe, popola un mapping dello spazio dei nomi che alla fine diventerà il __dict__ della classe. Il tipo di dict predefinito non garantisce l'ordine di inserimento nelle versioni più vecchie di Python e manca di ganci per convalidare o trasformare i nomi al momento della loro definizione. Gli sviluppatori che necessitano di vincoli di dichiarazione—come vietare determinati schemi di denominazione o tracciare l'ordine dei campi per protocolli binari—non avevano alcun meccanismo pulito per collegarsi a questa fase specifica della costruzione della classe prima che l'oggetto classe fosse finalizzato.
Implementando __prepare__ come un metodo statico in una metaclasse, puoi restituire un mapping mutabile personalizzato (come collections.OrderedDict o un dizionario di convalida personalizzato) da utilizzare come spazio dei nomi. Questo mapping cattura tutte le assegnazioni a livello di classe durante l'esecuzione del corpo, consentendo la preelaborazione prima che il metodo __new__ della metaclasse finalizzi la classe. Lo spazio dei nomi personalizzato viene quindi passato a __new__, dove può essere convertito in un dict standard o mantenuto per un accesso ordinato.
from collections import OrderedDict class OrderPreservingMeta(type): @staticmethod def __prepare__(name, bases, **kwargs): return OrderedDict() def __new__(mcs, name, bases, namespace, **kwargs): ordered_attrs = list(namespace.keys()) cls = super().__new__(mcs, name, bases, dict(namespace)) cls._declaration_order = ordered_attrs return cls class Schema(metaclass=OrderPreservingMeta): id = 1 name = "test" value = 3.14 print(Schema._declaration_order) # ['id', 'name', 'value']
Una piattaforma di trading finanziario aveva bisogno di generare formati di messaggio binari in cui l'ordine dei campi nell'intestazione del protocollo corrispondesse rigorosamente all'ordine di dichiarazione nella definizione della classe messaggio Python. Riordinare i campi avrebbe compromesso la compatibilità con i parser legacy C++ sul lato dell'exchange, causando rifiuti di scambi o crash di sistema.
Soluzione A: Indicizzazione manuale. Gli sviluppatori avrebbero annotato ogni campo con un numero di sequenza come field_order = 1. Questo approccio è esplicito e facile da comprendere per i principianti. Tuttavia, viola il principio DRY e diventa un onere di manutenzione durante il refactoring, poiché inserire un campo nel mezzo richiede di rinumerare tutti i campi successivi.
Soluzione B: Analisi del codice sorgente. Il framework potrebbe utilizzare il modulo AST per analizzare la definizione della classe e estrarre l'ordine delle assegnazioni. Questo funziona senza complessità di metaclasse. Sfortunatamente, fallisce completamente quando i file sorgente non sono disponibili a runtime, come nelle distribuzioni binarie congelate o nei deployment ottimizzati di CPython che rimuovono il codice sorgente.
Soluzione C: Metaclasse con __prepare__. Restituendo un OrderedDict da __prepare__, la metaclasse cattura automaticamente l'ordine naturale di dichiarazione. Questo è robusto in tutti gli scenari di deployment e trasparente per gli utenti finali. L'unico inconveniente è la complessità aggiuntiva per comprendere il protocollo di metaclasse di Python, che richiede conoscenze a livello senior.
Soluzione scelta: Il team ha selezionato la Soluzione C perché fornisce garanzie di tempo di definizione senza oneri a runtime per ogni istanza di messaggio. Funziona in modo affidabile in tutti gli ambienti di deployment, inclusi quelli senza codice sorgente, e mantiene la sintassi naturale della classe che gli sviluppatori si aspettano, mentre impone vincoli nella fase più precoce possibile.
Risultato: La libreria di messaggi ha mantenuto automaticamente la compatibilità con il formato wired. Gli sviluppatori hanno scritto definizioni di classe naturali, e il sistema ha generato layout binari corretti. Le gerarchie di ereditarietà hanno correttamente preservato l'ordine dei campi parentali prima dei campi figli, risolvendo un problema complesso nella specifica del protocollo di trading senza intervento manuale.
Domanda 1: Perché __prepare__ deve essere definito come un @staticmethod (o @classmethod) piuttosto che come un normale metodo di istanza, e quale errore si verifica se ometti questo decoratore?
Risposta: __prepare__ viene invocato prima che l'istanza della metaclasse venga creata, significando che non c'è cls o self disponibile per il binding. Python chiama __prepare__ per generare lo spazio dei nomi che verrà passato a __new__. Se definito come un normale metodo di istanza che si aspetta self, Python solleverà un TypeError che indica che la funzione accetta argomenti posizionali ma non ne sono stati forniti, poiché la macchina tenta di chiamarlo solo con il nome, le basi e gli argomenti keyword. Deve essere un metodo statico per essere chiamato senza binding implicito del primo argomento, anche se classmethod funziona se hai bisogno di accesso alla metaclasse stessa.
Domanda 2: Può __prepare__ restituire un mapping che non è un sottotipo di dict, e quale protocollo specifico deve soddisfare per funzionare correttamente durante l'esecuzione del corpo della classe?
Risposta: Sì, può restituire qualsiasi mapping mutabile che implementa il protocollo della classe base astratta MutableMapping, richiedendo specificamente __setitem__, __getitem__, __contains__, e idealmente __iter__ o keys() per la conversione. Tuttavia, il mapping non deve ereditare da dict. Il requisito critico è che deve accettare chiavi di stringa e valori arbitrari, comportandosi come un dizionario durante l'assegnazione degli attributi nel corpo della classe. Dopo l'esecuzione della classe, la metaclasse __new__ riceve questo mapping; se non è un sottotipo di dict, devi esplicitamente convertirlo (ad esempio, dict(namespace)) prima di chiamare super().__new__, poiché il __dict__ dell'oggetto classe risultante deve essere un dizionario.
Domanda 3: Come gestisce __prepare__ gli argomenti keyword passati nell'intestazione della definizione della classe (ad esempio, class MyClass(metaclass=Meta, strict=True)), e cosa succede se questi non vengono inoltrati correttamente?
Risposta: Gli argomenti keyword nell'intestazione della classe (oltre a metaclass) vengono passati a __prepare__ come **kwds. Se __prepare__ non accetta **kwargs (o argomenti denominati specifici), Python solleverà un TypeError che afferma che __prepare__ ha ricevuto un argomento keyword inaspettato. Questo è un pitfall comune quando si aggiungono opzioni di configurazione alle metaclassi. La firma del metodo deve essere __prepare__(name, bases, **kwargs) per essere compatibile con il futuro. Queste parole chiave vengono anche successivamente passate a __new__ e __init__, consentendo alla metaclasse di ricevere configurazioni al momento della preparazione per personalizzare il comportamento dello spazio dei nomi (ad esempio, scegliere tra modalità di convalida rigorosa e flessibile).