Typage
En Python, le type est porté par la valeur, pas par la variable. On peut enrichir le code avec des annotations et des vérificateurs (mypy, Pyright) sans perdre la souplesse du langage.
Typage dynamique vs statique
Python est dynamiquement typé : une variable peut référencer des valeurs de types différents au fil du temps. Des langages comme C++ ou Rust sont statiquement typés : le type est fixé à la compilation.
En python :
Chargement…
En C++ :
Chargement…
Ce n’est pas qu’une question de syntaxe : en Python, c’est l’objet qui a un type (int, str, list, …). La variable n’est qu’une étiquette vers cet objet.
Duck typing
Python s’appuie souvent sur le duck typing : « si ça se comporte comme un canard, c’est un canard ». On ne teste pas le type exact, mais la présence de méthodes ou d’attributs attendus.
C’est très pratique pour des APIs souples. En revanche, une erreur de forme (mauvais objet passé en argument) peut n’apparaître qu’à l’exécution, parfois loin de l’appel fautif.
Quand l’absence de types devient pénible
Sur une petite fonction isolée, le typage implicite suffit. Sur une codebase large, on veut surtout éviter les bugs du type « ça marchait en dev, ça casse en prod ».
Chargement…
Sortie console
Sans annotations ni outil de contrôle, rien ne signale le problème tant qu’on n’exécute pas cette branche.
Les niveaux de typage en pratique
1. Typage dynamique pur
Aucune annotation : tout est résolu à l’exécution. C’est le comportement par défaut de Python.
Chargement…
Le piège : + ne fait pas la même chose selon le type (somme, concaténation…). Sans annotations, une colonne lue en str depuis un CSV peut passer inaperçue jusqu’au backtest.
2. Typage indicatif (annotations, gradual typing)
Depuis Python 3, on peut annoter paramètres et valeurs de retour. Ces annotations ne changent pas le comportement à l’exécution par défaut ; elles servent à la documentation, à l’IDE (autocomplétion, refactors) et aux vérificateurs statiques.
Chargement…
Avec mypy ou Pyright, on peut vérifier le projet avant l’exécution :
mypy src/
Exemple de ce qu’un outil peut remonter :
Chargement…
Le gradual typing signifie qu’on peut typer progressivement : commencer par les modules critiques, laisser le reste sans annotations au début.
3. Validation « stricte » à l’exécution (Pydantic, dataclasses)
Pour des données entrantes (API HTTP, JSON, config), les annotations seules ne suffisent pas : il faut valider et convertir au runtime. Pydantic s’appuie sur les annotations pour construire des modèles qui lèvent une erreur claire si la forme est incorrecte.
Chargement…
On reste en Python dynamique, mais on refuse tôt les données incohérentes — utile aux frontières du système (flux broker, fichiers de barres, config de backtest).
Résumé
| Approche | Quand l'utiliser |
|---|---|
| Dynamique pur | Scripts courts, prototypes, logique très polymorphe |
| Annotations + mypy/Pyright | Bibliothèques internes, code métier qui évolue |
| Pydantic (ou équivalent) | Entrées/sorties structurées (API, config, ETL) |
Les annotations ne remplacent pas les tests ; elles réduisent une classe d’erreurs avant l’exécution et rendent l’intention lisible pour les autres (et pour vous dans six mois). Personnellement, j'utilise le gradual typing dans mes gros projets mais il est probable que je finisse par utiliser Pydantic dans mon labo de recherche principal.
Ressources
- Concepts du système de types : https://typing.python.org/en/latest/spec/concepts.html
- Documentation du module
typing: https://docs.python.org/3/library/typing.html