Dans les premières versions de Python (avant 2.2), les méthodes étaient des objets typés distincts des fonctions, nécessitant des vérifications de type explicites pour gérer les états liés et non liés. L'introduction des nouvelles classes et du modèle de type/classe unifié dans Python 2.2 a éliminé le type de méthode en tant qu'entité séparée pour les fonctions, transférant la responsabilité de liaison au protocole des descripteurs. Cette évolution a permis aux fonctions de mettre en œuvre __get__, créant des méthodes liées dynamiquement uniquement lorsqu'elles sont accessibles via des instances, simplifiant ainsi le modèle d'objet de la langue et réduisant la complexité interne des types.
Lorsqu'un utilisateur définit une méthode à l'intérieur d'une classe, l'objet sous-jacent stocké dans le dictionnaire de classe est une fonction ordinaire s'attendant à ce que self soit son premier argument. Le défi consiste à garantir que lorsque cet attribut est récupéré via une instance (par exemple, obj.method), Python construit de manière transparente un appelable qui fournit automatiquement cette instance comme premier argument positionnel sans nécessiter d'application partielle manuelle ou de code d'emballage. Ceci doit se produire efficacement à chaque accès d'attribut tout en maintenant la capacité d'accéder à la fonction non liée via la classe (par exemple, Class.method) pour un passage explicite de self ou une inspection d'héritage.
Les fonctions mettent en œuvre le protocole des descripteurs via leur méthode __get__. Lorsqu'elles sont accessibles sur une classe (None instance), __get__ retourne l'objet fonction lui-même. Lorsqu'elles sont accessibles sur une instance, __get__(self, instance, owner) retourne un objet method qui encapsule à la fois la fonction et l'instance. Lors de l'invocation, cette méthode liée préfixe l'instance au tuple d'arguments avant d'appeler la fonction sous-jacente.
class Demo: def compute(self, value): return value * 2 d = Demo() # L'accès à la classe retourne la fonction brute unbound = Demo.__dict__['compute'] print(type(unbound)) # <class 'function'> # L'accès à l'instance déclenche __get__, retournant une méthode liée bound = unbound.__get__(d, Demo) print(type(bound)) # <class 'method'> print(bound(5)) # 10, équivalent à d.compute(5)
Développer un système de trading à haute fréquence nécessite que les objets de stratégie enregistrent des gestionnaires de mise à jour des prix avec un flux de données de marché. Initialement, les développeurs passaient strategy.on_price_update comme référence de rappel. Lors des tests de charge, le profilage mémoire a révélé que les stratégies supprimées n'étaient pas collectées par le garbage collector car le flux détenait des références de méthode liée, créant des cycles de références fortes accidentelles qui persistaient pendant toute la durée de l'application.
Une approche consistait à stocker des références faibles à la stratégie et à la fonction non liée séparément, puis à les combiner manuellement au moment de l'invocation. Cela empêche les références circulaires et permet une collecte immédiate des stratégies abandonnées. Cependant, cela introduit une logique d'invocation de rappel complexe, des conditions de compétition potentielles si l'objet est collecté entre le contrôle de la vitalité et l'appel, et brise l'idiome intuitif de passage de méthode de Python.
Une autre option consistait à convertir on_price_update en @staticmethod et à passer explicitement l'instance de stratégie lors de l'enregistrement. Cela simplifie la gestion des références en évitant complètement la création de méthodes liées. Malheureusement, cela viole les principes d'encapsulation orientée objet, oblige à modifier l'API d'enregistrement pour accepter à la fois la fonction et l'instance séparément, et produit un code moins lisible qui obscurcit la relation entre la stratégie et son gestionnaire.
Nous avons envisagé d'implémenter un descripteur personnalisé retournant un objet similaire à une méthode liée conservant une référence faible à l'instance au lieu d'une forte. Cela maintient la syntaxe d'appel obj.method et empêche les fuites de mémoire tout en restant idiomatique du point de vue de l'appelant. L'inconvénient est le besoin d'une connaissance approfondie du protocole des descripteurs pour l'implémenter correctement et le léger surcoût de vérification de la vitalité de la référence à chaque appel.
Nous avons sélectionné la Solution 3, mettant en œuvre un descripteur WeakMethod qui imite la liaison de fonction standard mais utilise weakref.ref pour l'instance. Cela a permis au flux de données de marché de conserver des rappels sans empêcher la collecte des stratégies par le garbage collector. L'approche a préservé un code d'enregistrement propre : feed.register(ticker, strategy.on_price_update).
Cette optimisation a éliminé les fuites de mémoire dans des sessions de trading de longue durée et réduit l'empreinte mémoire de 40 % lors des tests avec des millions d'instances de stratégie transitoires. Le système a maintenu un design d'API orienté objet propre sans exiger que les utilisateurs comprennent les complexités de gestion des références. En fin de compte, comprendre le mécanisme de création de méthode liée s'est avéré essentiel pour construire un logiciel financier de qualité production.
Pourquoi le stockage d'une méthode liée dans un conteneur de longue durée empêche-t-il la collecte des ordures de l'instance associée même après la disparition de toutes les références originales ?
Un objet méthode liée maintient un attribut interne __self__ contenant une référence forte à l'instance. Lorsqu'il est stocké dans un registre ou un cache global, la méthode maintient l'instance accessible indéfiniment. Pour éviter cela, les développeurs doivent utiliser weakref.WeakMethod ou stocker des fonctions non liées avec des références faibles d'instance séparées.
Comment l'implémentation de __get__ du descripteur @classmethod diffère-t-elle des fonctions standard pour permettre des méthodes de fabrique polymorphiques ?
classmethod est un descripteur non-donnée qui lie la classe owner au premier argument plutôt qu'à l'instance. Lorsqu'il est accessible sur une sous-classe, il reçoit cette sous-classe en tant que cls, permettant des constructeurs alternatifs qui instancient le bon type dérivé. Cela contraste avec les méthodes statiques, qui ne reçoivent aucune liaison automatique et ne peuvent pas déterminer la classe appelante sans inspection explicite.
Quel surcoût se produit au niveau de CPython lors de l'accès répété aux méthodes d'instance dans des boucles serrées, et pourquoi la mise en cache des méthodes améliore-t-elle les performances ?
Chaque accès obj.method déclenche le protocole des descripteurs, allouant un nouvel objet PyMethodObject sur le tas contenant des pointeurs vers la fonction et l'instance. Cette allocation et désallocation répétées entraînent un surcoût significatif dans des boucles à haute fréquence. La mise en cache de la méthode liée en dehors de la boucle permet de réutiliser le même objet, éliminant les coûts de recherche du descripteur et réduisant le temps d'exécution de 20 à 30 % dans les micro-benchmarks.