Les classes Protocol : typage structurel pour le duck typing en Python

Ce que c'est

Une classe Protocol (PEP 544, typing.Protocol) liste des méthodes et des attributs ; tout objet qui les fournit satisfait le type, que sa classe hérite ou non du protocole. La documentation de typing appelle cela le sous-typage structurel (duck typing statique), par opposition au sous-typage nominal par héritage. Les « artistes à un seul tour » de collections.abc, comme Iterable et Sized, sont les propres exemples de la bibliothèque standard. Un protocole peut être générique (class Reader[T](Protocol) depuis Python 3.12, Protocol[T] avant).

Pourquoi c'est important

Les fonctions qui acceptent « n'importe quoi possédant .read() » ou « n'importe quoi possédant .close() » sont partout en Python. Sans protocoles, elles sont annotées Any (aucune vérification) ou avec une classe concrète unique (les parties appelantes doivent en hériter). Un protocole permet à la partie consommatrice d'énoncer ce dont elle a besoin plutôt qu'à la partie productrice d'énoncer ce qu'elle est : le type vit à proximité du code qui en dépend, les classes tierces s'y conforment sans modification, et un double de test n'a besoin que des membres réellement utilisés.

Comment l'appliquer

• Définir le protocole dans le module consommateur et le garder minimal : uniquement les membres appelés par le consommateur, avec des signatures précises et des corps ....
• Utiliser des protocoles pour les types de paramètres et des classes de base abstraites pour l'implémentation partagée ; un protocole ne porte aucun code, une ABC le peut.
• N'ajouter @runtime_checkable que là où isinstance() est réellement nécessaire. La documentation indique que de tels contrôles ne testent que la présence des attributs indiqués et ignorent leurs signatures de type ; les protocoles sans ce décorateur ne peuvent pas du tout être utilisés avec isinstance().
• Nommer les protocoles d'après leur capacité (SupportsClose, Closable), à l'image de typing.SupportsInt et consorts.
• Vérifier la conformité de façon statique là où une dérive serait dommageable. La PEP 544 indique qu'un héritage explicite n'est pas nécessaire pour la vérification de type, mais qu'il permet au vérificateur de contrôler la classe dès sa définition et lui fournit des implémentations par défaut. L'alternative, qui consiste à affecter une instance à une variable annotée avec le protocole, fonctionne aussi ; la PEP la déconseille dans le code applicatif parce qu'elle se lit comme du code mort et nécessite une instance, donc à réserver à un module de test.

Pièges

Les membres d'attribut (name: str) sont satisfaits aussi bien par de simples attributs que par des propriétés, mais un vérificateur rejette une propriété en lecture seule là où un attribut modifiable est déclaré. Une méthode dont les noms de paramètres diffèrent de ceux du protocole peut être signalée comme incompatible, car les parties appelantes peuvent les passer par mot-clé ; marquer les paramètres comme positionnels uniquement (/) lorsque les noms ne font pas partie du contrat. La documentation note qu'un contrôle isinstance() contre un protocole vérifiable à l'exécution peut être étonnamment lent comparé à un contrôle de classe, et que les attributs affectés plus tard dans __init__ échouent au test de présence tant qu'ils ne sont pas définis. Les classes Protocol ne peuvent pas être instanciées. Hériter explicitement d'un protocole est autorisé, mais les lecteurs y voient alors une relation nominale là où elle n'était pas nécessaire.