Les descripteurs ont été formalisés dans Python 2.2 avec les classes de nouveau style pour fournir un protocole unifié pour le contrôle d'accès aux attributs. Avant cette innovation, les types intégrés comme property et classmethod reposaient sur une logique de cas particuliers codée en dur dans l'interpréteur. L'introduction du protocole des descripteurs a permis aux classes définies par l'utilisateur d'exhiber des comportements précédemment réservés aux intégrés. La convention qui consiste à passer None pour le paramètre d'instance est née de la nécessité de distinguer entre l'accès au niveau de la classe et au niveau de l'instance sans fragmenter le protocole en plusieurs méthodes.
Sans un mécanisme pour détecter quand l'accès se produit sur la classe elle-même, les descripteurs seraient contraints de se retourner inconditionnellement, empêchant ainsi la mise en œuvre de propriétés au niveau de la classe ou d'introspection de schéma. Alternativement, le protocole exigerait des méthodes de crochet distinctes pour l'accès de classe par rapport à l'accès d'instance, compliquant considérablement le modèle d'objet. Le défi était de concevoir une signature de méthode unique capable de gérer élégamment les deux modèles d'accès tout en maintenant la compatibilité ascendante et un minimum de surcharge de performance.
La signature de la méthode __get__(self, instance, owner) reçoit None pour le paramètre d'instance lorsqu'elle est accédée comme Class.attribute, et l'objet d'instance actuel lorsqu'elle est accédée comme instance.attribute. Le paramètre owner reçoit toujours la classe définissant l'attribut. Cela permet aux descripteurs d'implémenter une logique de branchement : retourner les métadonnées ou le descripteur lui-même lorsque instance is None, ou retourner des valeurs calculées lorsqu'une instance existe. Cette convention permet la mise en œuvre de classmethod et staticmethod en pur Python, et prend en charge des modèles avancés comme des schémas de validation au niveau de la classe.
Une équipe d'ingénierie des données nécessitait un cadre de validation déclaratif où les définitions de champs fournissaient des métadonnées lorsqu'elles étaient inspectées sur la classe pour la génération automatique de documentation OpenAPI, mais exécutaient des validations de données lorsqu'elles étaient accédées sur des instances. L'implémentation initiale utilisant des descripteurs naïfs a échoué car l'accès à User.email sur la classe retournait l'objet de descripteur brut, n'offrant aucune information de type ni contraintes.
Une approche envisagée était de mettre en œuvre des méthodes de classe distinctes pour la récupération de métadonnées. Cela impliquait de créer une méthode get_schema() qui inspectait manuellement le dictionnaire de la classe pour extraire les informations de champ. Bien que cela soit explicite et facile à comprendre pour les développeurs juniors, cela créait une déconnexion dangereuse entre les définitions de champs et leurs capacités d'introspection. Avantages : mise en œuvre simple nécessitant aucune connaissance avancée de Python. Inconvénients : violation du principe DRY, nécessité de maintenir des structures de logique parallèles, et s'est avérée sujette aux erreurs lorsque les définitions de champs évoluaient.
La deuxième approche a exploité la convention None du protocole de descripteur en vérifiant if instance is None à l'intérieur de __get__. Lorsque cette condition était vraie, le descripteur retournait un objet FieldSchema contenant des contraintes de type et des validateurs ; sinon, il effectuait la validation et retournait la valeur réelle. Avantages : API unifiée sous un seul nom d'attribut, suivait les conventions Pythonic et offrait un support d'héritage automatique. Inconvénients : nécessitait une compréhension approfondie du mécanisme de recherche d'attribut CPython et s'avérait plus difficile à déboguer pour les développeurs non familiers avec les internes des descripteurs.
Une troisième option impliquait l'utilisation d'une méta-classe pour intercepter la création de classe et injecter des propriétés synthétiques pour l'accès au schéma. Bien que cela offre un contrôle total sur le comportement de la classe, cela introduisait une complexité significative dans la hiérarchie des classes et compliquait les efforts de débogage. Avantages : contrôle comportemental total. Inconvénients : trop sur-conçu pour les exigences, affectait les calculs de l'ordre de résolution des méthodes, et augmentait considérablement le temps d'importation.
L'équipe a sélectionné la deuxième solution car cela exploitait les mécanismes existants de CPython sans introduire de couches d'abstraction supplémentaires. La vérification de None fournissait un contexte suffisant pour distinguer entre les modèles d'accès au temps de documentation et d'exécution tout en réduisant le code de quarante pour cent par rapport à l'approche de méthode explicite.
Le cadre résultant permettait à User.email de retourner un objet de schéma complet, tandis que user.email retournait la valeur de chaîne validée. Ce double comportement a permis la génération automatique de spécifications OpenAPI via une simple inspection de la classe, réduisant la maintenance de la documentation de quatre-vingt-dix pour cent et éliminant une catégorie entière de bogues de synchronisation entre mise en œuvre et documentation.
Comment les descripteurs de données (implémentant à la fois __get__ et __set__) diffèrent-ils des descripteurs non-données dans la priorité de recherche d'attributs, et pourquoi cette distinction empêche-t-elle les dictionnaires d'instance d'obscurcir les attributs de classe dans certains cas mais pas dans d'autres ?
Les descripteurs de données implémentent à la fois __get__ et __set__, tandis que les descripteurs non-données n'implémentent que __get__. Dans le mécanisme de résolution d'attributs de Python, les descripteurs de données ont la priorité sur le __dict__ de l'instance. Cela signifie que l'attribution à instance.attr invoquera toujours la méthode __set__ du descripteur, même si l'instance avait précédemment cette clé dans son dictionnaire. En revanche, les descripteurs non-données permettent au dictionnaire d'instance de les obscurcir ; si vous assignez instance.attr = value, l'instance gagne une nouvelle entrée dans __dict__, et les accès ultérieurs récupèrent cette valeur au lieu d'invoquer le descripteur. Cette distinction est cruciale pour mettre en œuvre des propriétés mises en cache (non-données) par rapport à des attributs en lecture seule (données). Les candidats passent souvent à côté du fait que le simple fait de définir __set__ modifie la sémantique de recherche même si la méthode se contente de lever AttributeError, ce qui est précisément comment les objets property imposent l'immuabilité.
Pourquoi les descripteurs personnalisés doivent-ils implémenter __set_name__ plutôt que de capturer le nom d'attribut dans __init__, notamment lorsque la même instance de descripteur est assignée à plusieurs attributs de classe ou utilisée avec héritage ?
Lorsqu'une seule instance de descripteur est assignée à plusieurs noms (par exemple, x = y = MyDescriptor()), stocker le nom dans __init__ entraîne l'écrasement du premier assignement lors du deuxième, ce qui conduit à une résolution de nom incorrecte. De plus, pendant l'héritage des classes, les descripteurs de la classe parente ne sont pas ré-initialisés pour les sous-classes. La méthode __set_name__, introduite dans Python 3.6, est invoquée par l'interpréteur exactement une fois lors de la création de la classe, recevant à la fois la classe propriétaire et le nom de l'attribut. Cela garantit un lien correct même avec des héritages complexes ou plusieurs assignations. Sans cette méthode, les descripteurs ne peuvent pas générer de messages d'erreur précis ou effectuer une introspection nécessitant leur nom d'attribut, entraînant des échecs silencieux lors d'opérations de métaprogrammation.
Comment le protocole des descripteurs interagit-il avec __slots__, et quel mode de défaillance spécifique se produit lorsque un descripteur personnalisé dans une classe utilisant __slots__ partage son nom avec un slot ?
Le mécanisme __slots__ de Python implémente des descripteurs de données en interne pour gérer le stockage d'attributs dans des tableaux de taille fixe plutôt que dans des dictionnaires. Lorsque vous définissez __slots__ = ['name'], CPython crée un descripteur pour name dans le dictionnaire de classe. Si vous définissez ensuite un descripteur personnalisé avec def name(self): ..., vous remplacez le descripteur de slot, brisant entièrement le mécanisme de slot. Cela provoque une AttributeError car le descripteur personnalisé n'a pas les protocoles de slot au niveau C nécessaires pour accéder au stockage des slots. Les candidats oublient souvent que les descripteurs de slot sont des descripteurs de données avec des implémentations C spécialisées. La solution nécessite soit d'utiliser un nom d'attribut distinct pour le descripteur personnalisé, soit de déléguer soigneusement aux méthodes __get__ et __set__ du descripteur de slot d'origine, bien que cela nécessite une gestion rigoureuse pour éviter une récursivité infinie.