Le Python Language Summit 2026 étudie l’introduction d’un espace de noms std dédié

Lors du Python Language Summit 2026, Pablo Galindo Salgado, membre du Steering Council et responsable des versions, a ouvert les débats sur l'introduction d'un espace de noms de premier niveau dédié à la bibliothèque standard de Python, selon un compte rendu publié par le blog du projet.

Le problème de l'espace de noms plat

Python s'appuie actuellement sur un espace de noms de modules plat. Cette structure engendre régulièrement des exceptions AttributeError déroutantes lorsque des fichiers du projet local ou des dépendances tierces partagent leur nom avec des modules standard tels que json, math ou random. Ce masquage survient car les emplacements prioritaires dans sys.path, comme le répertoire de travail actuel, l'emportent sur les importations de la bibliothèque standard. Bien que Python 3.11 ait introduit l'option -P pour éviter la prépondérance de chemins non sécurisés, la plupart des utilisateurs ne l'activent pas.

Au-delà des difficultés de débogage pour les débutants, cet espace de noms plat contraint les développeurs du cœur du langage à choisir des noms peu naturels ou à ajouter des suffixes comme lib (à l'image de tomllib ou graphlib) pour les nouveaux modules, afin d'éviter tout conflit avec les paquets existants sur PyPI.

L'espace de noms std proposé et le découplage

La solution envisagée propose un nouvel espace de noms std au sommet de la hiérarchie, permettant d'importer explicitement les modules standard via std.json ou grâce à une syntaxe du type from std import json. Les importations actuelles continueraient de fonctionner indéfiniment afin de préserver la compatibilité ascendante, tandis que les futurs modules pourraient être réservés exclusivement à ce nouvel espace.

Un effet secondaire potentiel de cette réservation d'espace est la possibilité de découpler la bibliothèque standard, autorisant ainsi la distribution et la mise à jour des modules de manière indépendante sur PyPI, en dehors des cycles de sortie de l'interpréteur. Toutefois, les participants ont souligné certains risques en citant l'expérience de Ruby avec la « gemification » de sa bibliothèque standard, marquée par de longues périodes d'obsolescence et des vulnérabilités non corrigées dans des gemmes non gérées.

Retour des participants et alternatives syntaxiques

Au fil des échanges lors du sommet, les détails de mise en œuvre ont suscité des débats. Stefan Behnel et Guido van Rossum ont évoqué l'idée de restreindre ce changement aux importations de type from, comme from std import random, afin de conserver le code utilisateur quasi intact et d'éviter la duplication des modules dans sys.modules. Un sondage indicatif dans la salle a révélé un accueil favorable à l'exploration d'options syntaxiques basées sur des mots-clés.

Gregory P. Smith a invité à la prudence, soulignant que cette proposition tente de résoudre plusieurs problèmes distincts simultanément. Il a conseillé à l'équipe principale de garder toutes les pistes ouvertes tout en définissant clairement les priorités à traiter en premier.

Illustration éditoriale générée par IA ; ce n’est pas une photographie documentaire.

Source: One namespace to namespace them all (Python Language Summit 2026)