Python 3.15 est sorti : UTF-8 par défaut, imports paresseux et un compilateur JIT renforcé

Technique · Atelier

Ne charger un module que s’il sert : comment fonctionnent les imports paresseux de Python 3.15

Un gros programme Python peut mettre plusieurs secondes à démarrer, simplement parce qu’il importe au lancement des dizaines de modules dont il n’utilisera qu’une partie. Python 3.15 ajoute le mot-clé lazy (PEP 810) pour régler ce problème proprement. Atelier pédagogique.

1. Pourquoi un import coûte cher. Quand Python rencontre import module, il doit trouver le fichier sur le disque, le lire, le compiler en bytecode s’il n’est pas déjà en cache, puis exécuter tout le code placé au premier niveau du module, qui importe souvent lui-même d’autres modules. Pour un outil en ligne de commande, chaque --help ou chaque petite sous-commande paie ainsi le prix de tout l’arbre de dépendances. Jusqu’ici, on contournait le problème en déplaçant les imports à l’intérieur des fonctions. Ça marche, mais les dépendances sont alors éparpillées dans le code et plus difficiles à suivre.

2. Ce que fait lazy. On écrit lazy import json ou lazy from pathlib import Path en tête de fichier, comme d’habitude. Python ne charge rien à ce moment-là : il place sous ce nom un objet intermédiaire léger. Le vrai chargement se fait de façon transparente à la première utilisation du nom, par exemple au premier json.loads(...). On garde la lisibilité des imports regroupés en haut du fichier, et on ne paie que pour les modules réellement utilisés pendant l’exécution.

3. Ce qui change pour les erreurs. Un import classique échoue tout de suite si le module manque. Avec un import paresseux, l’erreur n’apparaît qu’à la première utilisation, peut-être bien plus tard, dans une branche rarement exécutée. Python l’a prévu : la trace d’erreur montre à la fois l’endroit où le nom a été utilisé et la ligne de l’import d’origine. Conséquence pratique : les tests doivent passer par les chemins qui utilisent chaque dépendance paresseuse, sinon un module manquant peut ne se révéler qu’en production. Autre point : un module dont le chargement a des effets de bord (enregistrer un plugin, modifier une configuration globale) ne les produira qu’au premier usage. Ce code-là doit rester en import normal.

4. Les limites et les réglages. lazy n’est permis qu’au niveau du module : dans une fonction, une classe ou un bloc try/except, c’est une erreur de syntaxe, de même que lazy from module import *. Pour tester sans modifier le code, l’option -X lazy_imports=all ou la variable PYTHON_LAZY_IMPORTS rend tous les imports paresseux ; sys.set_lazy_imports_filter() permet de choisir, par exemple, de ne rendre paresseux que les modules de sa propre application et de garder les bibliothèques tierces en chargement immédiat. Pour du code qui doit aussi tourner sur des versions plus anciennes, un module peut déclarer __lazy_modules__ = ["json", "pathlib"] : ses imports normaux de ces modules deviennent paresseux sous 3.15 et restent ordinaires ailleurs. Bonne méthode : mesurer d’abord le temps de démarrage (l’option -X importtime détaille le coût de chaque import), puis rendre paresseux les modules lourds et rarement utilisés, plutôt que tout d’un coup.

Sources : Python.org, « What’s new in Python 3.15 », PEP 810 · LWN.net, 09.10.2026 — atelier pédagogique