La méthode __prepare__ a été introduite dans Python 3.0 via PEP 3115 pour résoudre des limitations fondamentales dans le protocole de création de classe. Avant ce changement, l'espace de noms utilisé pendant l'exécution du corps de la classe était toujours un dictionnaire standard, sans possibilité de préserver l'ordre de déclaration des attributs ou d'intercepter les affectations au fur et à mesure qu'elles se produisaient. Cela est devenu particulièrement problématique pour les développeurs construisant des ORM et des bibliothèques de sérialisation qui devaient suivre la séquence des déclarations de champs sans recourir à une analyse fragile du code source.
Lorsque Python exécute un corps de classe, il remplit une correspondance d'espace de noms qui deviendra finalement le __dict__ de la classe. Le type dict par défaut ne garantit pas l'ordre d'insertion dans les anciennes versions de Python et n'offre pas d'accroches pour valider ou transformer les noms au moment où ils sont définis. Les développeurs nécessitant des contraintes au moment de la déclaration—comme interdire certains schémas de nommage ou suivre l'ordre des champs pour des protocoles binaires—n'avaient aucun mécanisme propre pour se raccrocher à cette phase spécifique de construction de classe avant que l'objet classe ne soit finalisé.
En implémentant __prepare__ comme méthode statique dans une métaclasse, vous pouvez retourner un mappage mutable personnalisé (tel que collections.OrderedDict ou un dictionnaire de validation personnalisé) pour servir d'espace de noms. Ce mappage capture toutes les affectations de niveau classe pendant l'exécution du corps, permettant un prétraitement avant que la méthode __new__ de la métaclasse ne finalise la classe. L'espace de noms personnalisé est ensuite passé à __new__, où il peut être converti en un dict standard ou préservé pour un accès ordonné.
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']
Une plateforme de trading financier devait générer des formats de message binaire où l'ordre des champs dans l'en-tête du protocole correspondait strictement à l'ordre de déclaration dans la définition de la classe de message Python. Réorganiser les champs casserait la compatibilité avec les analyseurs C++ hérités côté échange, provoquant des rejets de transactions ou des plantages système.
Solution A : Indexation manuelle. Les développeurs annotaient chaque champ avec un numéro de séquence comme field_order = 1. Cette approche est explicite et facile à comprendre pour les débutants. Cependant, elle enfreint le principe DRY et devient un fardeau de maintenance lors de la refactorisation, car insérer un champ au milieu nécessite de renuméroter tous les champs suivants.
Solution B : Analyse du code source. Le cadre pourrait utiliser le module AST pour analyser le code source de la définition de la classe et extraire l'ordre des affectations. Cela fonctionne sans la complexité des métaclasses. Malheureusement, cela échoue complètement lorsque les fichiers source ne sont pas disponibles à l'exécution, comme dans les distributions binaires gelées ou les déploiements CPython optimisés qui suppriment le code source.
Solution C : Métaclasse avec __prepare__. En retournant un OrderedDict depuis __prepare__, la métaclasse capture automatiquement l'ordre naturel de déclaration. Cela est robuste dans tous les scénarios de déploiement et transparent pour les utilisateurs finaux. Le seul inconvénient est la complexité supplémentaire de la compréhension du protocole des métaclasses de Python, qui nécessite des connaissances de niveau senior.
Solution choisie : L'équipe a choisi la solution C car elle fournit des garanties au moment de la définition sans surcharge à l'exécution par instance de message. Elle fonctionne de manière fiable dans tous les environnements de déploiement, y compris ceux sans code source, et maintient la syntaxe naturelle de classe que les développeurs attendent tout en appliquant des contraintes au plus tôt possible.
Résultat : La bibliothèque de messages a maintenu la compatibilité avec le format de fil automatiquement. Les développeurs ont écrit des définitions de classe naturelles, et le système a généré des mises en page binaires correctes. Les hiérarchies d'héritage préservaient correctement l'ordre des champs parent avant les champs enfant, résolvant un problème complexe dans la spécification du protocole de trading sans intervention manuelle.
Question 1 : Pourquoi __prepare__ doit-il être défini comme un @staticmethod (ou @classmethod) plutôt que comme une méthode d'instance normale, et quelle erreur se produit si vous omettez ce décorateur ?
Réponse : __prepare__ est invoqué avant que l'instance de métaclasse ne soit créée, ce qui signifie qu'il n'y a pas encore de cls ou self disponibles pour lier. Python appelle __prepare__ pour générer l'espace de noms qui sera passé à __new__. Si elle est définie comme une méthode d'instance normale s'attendant à self, Python soulèvera une TypeError indiquant que la fonction prend des arguments positionnels mais aucun n’a été donné, car la machinerie tente de l'appeler avec seulement le nom, les bases et les arguments clés. Elle doit être une méthode statique pour être appelée sans liaison implicite du premier argument, bien que classmethod fonctionne si vous avez besoin d'accéder à la métaclasse elle-même.
Question 2 : __prepare__ peut-il retourner un mappage qui n'est pas un sous-classe de dict, et quel protocole spécifique doit-il respecter pour fonctionner correctement pendant l'exécution du corps de la classe ?
Réponse : Oui, il peut retourner tout mappage mutable implémentant le protocole de classe de base abstraite MutableMapping, nécessitant spécifiquement __setitem__, __getitem__, __contains__, et idéalement __iter__ ou keys() pour la conversion. Cependant, le mappage n'a pas besoin d'hériter de dict. L'exigence critique est qu'il doit accepter des clés de chaîne et des valeurs arbitraires, se comportant comme un dictionnaire lors de l'affectation d'attribut dans le corps de la classe. Après l'exécution de la classe, la métaclasse __new__ reçoit ce mappage ; s'il n'est pas une sous-classe de dict, vous devez explicitement le convertir (par exemple, dict(namespace)) avant d'appeler super().__new__, puisque le __dict__ de l'objet classe résultant doit être un dictionnaire.
Question 3 : Comment __prepare__ gère-t-il les arguments de mots-clés passés dans l'en-tête de la définition de classe (par exemple, class MyClass(metaclass=Meta, strict=True)), et que se passe-t-il si ceux-ci ne sont pas transmis correctement ?
Réponse : Les arguments de mots-clés dans l'en-tête de la classe (au-delà de metaclass) sont passés à __prepare__ comme **kwds. Si __prepare__ n'accepte pas **kwargs (ou des arguments nommés spécifiques), Python soulèvera une TypeError indiquant que __prepare__ a reçu un argument de mot-clé inattendu. C'est un piège courant lors de l'ajout d'options de configuration aux métaclasses. La signature de la méthode doit être __prepare__(name, bases, **kwargs) pour être compatible en avant. Ces mots-clés sont également passés ultérieurement à __new__ et __init__, permettant à la métaclasse de recevoir des configurations au moment de la préparation pour personnaliser le comportement de l'espace de noms (par exemple, choisir entre des modes de validation stricte et permissive).