Historique de la question. Avant Python 3.7, la mise en œuvre des types génériques nécessitait une métaclasse complexe TypingMeta qui interceptait getitem pour gérer le sous-typage comme List[int]. Cette approche était lente, créait des dépendances circulaires au sein du module typing lui-même, et compliquait le débogage car chaque opération générique traversait une logique de métaclasse lourde. La PEP 560 a introduit un protocole dédié pour résoudre ces problèmes de performance et d'architecture.
Le problème. Les classes génériques doivent accepter des arguments de type (comme int dans List[int]) au niveau de la classe, pas au niveau de l'instance, pour prendre en charge la vérification de type statique et l'introspection à l'exécution sans créer de vraies instances. Le défi consistait à stocker ces arguments dans un objet léger qui préserve la relation entre l'origine générique et ses paramètres, tout en permettant aux classes d'être sous-typées plusieurs fois sans invoquer init.
La solution. Python 3.7+ met en œuvre la méthode magique class_getitem sur la classe de base Generic, qui est automatiquement invoquée lorsqu'une classe est sous-typée (par exemple, Container[int]). Cette méthode renvoie un objet GenericAlias (type interne _GenericAlias dans CPython) qui stocke la classe d'origine dans origin et les arguments de type dans args. Le mécanisme évite toute instanciation et met en cache ces objets alias pour plus d'efficacité.
from typing import Generic, TypeVar T = TypeVar('T') class Container(Generic[T]): def __init__(self, value: T) -> None: self.value = value # La sous-typage à l'exécution crée un GenericAlias, pas une instance SpecializedType = Container[int] print(SpecializedType) # <class '__main__.Container[int]'> print(SpecializedType.__origin__) # <class '__main__.Container'> print(SpecializedType.__args__) # (<class 'int'>,) # L'instanciation se produit séparément instance = SpecializedType(42)
Description du problème. Une bibliothèque de validation de données devait analyser des structures JSON imbriquées en objets Python basés sur des indications de type fournies par l'utilisateur comme Dict[str, List[User]] ou Optional[Tuple[int, str]]. Le principal défi était de déterminer, à l'exécution, quels types étaient contenus dans les conteneurs génériques pour instancier récursivement les bons sous-objets, sans coder en dur chaque combinaison possible de génériques.
Solution 1 : Analyse de chaîne des représentations de type. Avantages : Rapide à mettre en œuvre en utilisant str(type_hint) et regex. Inconvénients : Extrêmement fragile, échoue sur les références avancées, les unions de types, ou les génériques imbriqués, et ne parvient pas à distinguer entre des types aux noms similaires dans différents modules.
Solution 2 : Enregistrement de métaclasse manuelle nécessitant que les utilisateurs décorent chaque classe générique. Avantages : Contrôle total sur le stockage et la récupération des paramètres de type. Inconvénients : Met une lourde charge sur les utilisateurs de la bibliothèque, crée des conflits de métaclasses lorsque leurs classes utilisent déjà des métaclasses personnalisées, et duplique des fonctionnalités déjà présentes dans la bibliothèque standard.
Solution 3 : Exploiter l'introspection class_getitem via get_origin() et get_args(). Avantages : Utilise le protocole standard GenericAlias, gère de manière robuste les structures imbriquées arbitrairement, et respecte le MRO pour des hiérarchies d'héritage complexes sans code utilisateur supplémentaire. Inconvénients : Nécessite une compréhension des attributs internes comme origin qui sont techniquement des détails de mise en œuvre, bien que stabilisés dans les versions modernes de Python.
Solution choisie. La solution 3 a été sélectionnée car elle est alignée avec la PEP 560 et l'architecture moderne du système de type Python. En vérifiant get_origin(type_hint) pour trouver le conteneur de base (par exemple, dict) et get_args(type_hint) pour extraire les types paramétrés (par exemple, str, User), la bibliothèque construit récursivement des validateurs. Cette approche fonctionne sans couture avec les génériques définis par l'utilisateur héritant de Generic[T] sans nécessiter de modifications de leurs définitions de classe.
Résultat. La bibliothèque désérialise avec succès des charges utiles imbriquées complexes en objets Python sûrs pour les types. Les utilisateurs peuvent définir class PaginatedResponse(Generic[T]): ... et le système extrait automatiquement T lors de la rencontre de PaginatedResponse[OrderDetail], instanciant le bon sous-arbre générique tout en maintenant des informations de type complètes pour le support IDE et la validation à l'exécution.
Pourquoi isinstance([1, 2, 3], List[int]) soulève-t-il une TypeError, et comment cette limitation reflète-t-elle la distinction entre les alias de type génériques et les types concrets à l'exécution ?
Python's isinstance nécessite que son deuxième argument soit un type, un tuple de types ou un objet avec une méthode instancecheck. List[int] est un objet GenericAlias créé par class_getitem, pas une classe. Parce que Python utilise le typage progressif, les paramètres génériques sont effacés à l'exécution ; la liste [1,2,3] n'a aucun souvenir d'avoir été paramétrée comme List[int] contre List[str]. Tenter isinstance sur un GenericAlias soulève TypeError: isinstance() arg 2 must be a type, tuple of types, or a union. Pour vérifier la compatibilité, il faut valider la structure manuellement ou utiliser des Protocols @runtime_checkable, qui ne vérifient que la présence de méthodes, pas les paramètres génériques.
Comment class_getitem interagit-il avec l'ordre de résolution de méthode lorsque une classe hérite de plusieurs parents génériques spécialisés, comme la classe MyMapping(Dict[str, int], Mapping[str, Any]) ?
Lorsque Python crée MyMapping, il traite chaque classe de base. Dict[str, int] et Mapping[str, Any] sont tous deux des objets GenericAlias résultant d'appels class_getitem sur leurs origines respectives. Le calcul du MRO traite ces derniers comme des bases distinctes, mais la machinerie Generic stocke les bases sous-typées d'origine dans orig_bases pour préserver l'information sur les arguments de type. Cela permet à get_type_hints(MyMapping) de résoudre que MyMapping est paramétré par str et int de la branche Dict, tandis que la branche Mapping fournit la conformité structurelle. Le détail clé est que class_getitem n'est pas rappelé à nouveau lors de l'héritage ; au lieu de cela, les alias existants sont attachés à la nouvelle classe, et mro_entries (pour certaines classes de base abstraites) peut ajuster le MRO final pour s'assurer que les classes d'origine génériques apparaissent correctement.
Quelle est la distinction entre parameters sur une définition de classe générique versus args sur un GenericAlias spécialisé, et pourquoi le sous-typage d'un générique avec un TypeVar entraîne-t-il que args contient l'objet TypeVar lui-même au lieu de son borne ?
parameters est un tuple d'attribut de classe contenant les objets TypeVar formels (par exemple, T) déclarés dans l'en-tête de la classe, représentant les emplacements de type abstraits du générique. args apparaît sur l'instance GenericAlias créée par class_getitem et contient les types concrets substitués pour ces paramètres (par exemple, int). Lorsque vous créez Container[T] où T est un TypeVar (commun à l'intérieur d'une autre fonction générique), args contient l'instance TypeVar parce que le lien concret est retardé jusqu'à ce que la portée externe fournisse un type spécifique. Ce mécanisme prend en charge des motifs génériques d'ordre supérieur, permettant des types comme Callable[[T], T] de préserver la relation entre les types d'entrée et de sortie à travers plusieurs niveaux d'abstraction générique, en utilisant l'attribut bound du TypeVar uniquement lorsque la résolution finale se produit via typing.get_type_hints().