Philosophie de l'ingénierie : Guido van Rossum, la lisibilité compte

Points clés

• Le code est lu bien plus souvent qu’il n’est écrit : van Rossum a donc optimisé Python pour l’humain qui lira la ligne plus tard, et non pour la machine ou l’auteur sur l’instant.
• L’indentation significative rend la lecture honnête : l’indentation que vous voyez est la structure de blocs qui s’exécute, si bien que l’apparence d’un programme Python ne peut pas mentir sur ce qu’il fait.
• « Il devrait y avoir une seule manière évidente de le faire » signifie qu’un code écrit par des inconnus se lit toujours comme s’il avait été écrit d’une seule main : la convergence vers un idiome unique est un cadeau fait à chaque lecteur futur.
• Le Zen de Python est l’œuvre de Tim Peters, pas de van Rossum : une erreur d’attribution courante. Peters a distillé des valeurs qui étaient déjà intégrées au langage.

Le principe

« L’une des intuitions clés de Guido est que le code est lu bien plus souvent qu’il n’est écrit. » – PEP 8, attribuant cette intuition à Guido van Rossum¹

Cette intuition est l’affirmation révolutionnaire la plus discrète de toute la conception de langages, et presque tout le monde l’approuve d’un hochement de tête avant de l’ignorer. Lisez la phrase lentement. Le code est lu bien plus souvent qu’il n’est écrit. Une ligne que vous tapez une fois sera lue des dizaines de fois — par le relecteur qui l’approuve, le collègue qui l’étend, l’inconnu qui en hérite, et le plus souvent par vous, six mois plus tard, à tenter de vous rappeler ce que vous vouliez dire. Si c’est vrai, alors le public du code source n’est ni la machine ni l’auteur au moment où il écrit. C’est l’humain qui le lit plus tard. Et un langage devrait être optimisé pour son public réel.

Presque aucun ne l’était. Les langages systèmes des années 1980 étaient optimisés pour le compilateur et la machine ; les langages de script l’étaient pour le confort de l’auteur sur l’instant, ce qui explique pourquoi tant d’entre eux devenaient illisibles dès le lendemain de leur écriture. Le pari de Guido van Rossum, c’était qu’on pouvait plutôt optimiser pour le lecteur — que la clarté, érigée en valeur par défaut et imposée par la grammaire elle-même, produirait des intérêts composés à l’échelle d’une communauté entière, sur des décennies. Il avait raison dans une mesure que presque personne n’avait anticipée. Le Zen de Python distille cette même valeur en trois mots que tout programmeur Python a lus : « La lisibilité compte. »²

Cette conviction est exactement celle qui sous-tend l’idée que le goût est un système technique plutôt qu’une intuition qu’on affirme. La lisibilité n’est pas une vague préférence qu’on greffe après coup avec un guide de style. Dans Python, elle est structurelle — inscrite dans la syntaxe, de sorte que le langage ne vous laisse pas écrire la version illisible aussi facilement que la lisible. Le pari de van Rossum, c’était qu’en faisant de la clarté la voie de moindre résistance, tout un écosystème dériverait vers la clarté sans qu’on le lui ordonne.

Contexte

Guido van Rossum est né le 31 janvier 1956 à La Haye, aux Pays-Bas, et a obtenu un master de mathématiques et d’informatique à l’université d’Amsterdam en 1982.³ Il est allé travailler au Centrum Wiskunde & Informatica (CWI), l’institut national néerlandais de recherche en mathématiques et informatique, à Amsterdam, où l’attendait l’expérience formatrice de sa carrière : le langage de programmation ABC.

ABC, conçu au CWI par Leo Geurts, Lambert Meertens et Steven Pemberton, était un langage pédagogique pensé pour être facile à apprendre et à lire, et van Rossum a passé plusieurs années, au milieu des années 1980, à travailler sur son implémentation.⁴ ABC reposait sur deux choix qui allaient résonner dans tout ce qu’il ferait ensuite : il utilisait l’indentation pour marquer la structure de blocs — la « règle du hors-jeu » (off-side rule), sans accolades, sans begin/end — et il érigeait la lisibilité en objectif de conception primordial, avec des programmes faisant en général le quart de la taille de leur équivalent Pascal ou C.⁴ Van Rossum en est venu à adorer l’idée de l’indentation ; il a dit plus tard qu’elle mettait fin aux vaines guerres de religion sur l’emplacement des accolades.⁵ Mais ABC souffrait aussi de défauts fatals — une implémentation monolithique, une conception fermée et difficile à étendre, un isolement académique qui le tenait à l’écart des vrais programmeurs Unix. Il avait utilisé le langage lisible et vu les deux moitiés de la leçon : quelles idées étaient réellement bonnes, et quelles erreurs l’avaient tué.

Vient ensuite la célèbre histoire des origines, et elle s’est vraiment déroulée comme le dit la légende. « Il y a un peu plus de six ans, en décembre 1989, écrivait van Rossum, je cherchais un projet de programmation “de loisir” qui m’occuperait pendant la semaine autour de Noël. »⁶ Son bureau au CWI était fermé pour les fêtes. Il s’est attelé à construire un langage de script qui conservait les meilleures idées d’ABC — la lisibilité, l’indentation — tout en corrigeant ses erreurs, en visant cette fois les hackers Unix/C qu’ABC n’avait jamais touchés. Pour le nom, « d’humeur légèrement irrévérencieuse (et grand fan du Monty Python’s Flying Circus) », il a choisi Python.⁶ Pas le serpent. La troupe comique. Il a publié la première version en 1991.³

L’œuvre

Lisibilité et indentation significative

La décision de conception la plus lourde de conséquences que van Rossum a reprise d’ABC est celle dont les nouveaux venus débattent et que les vétérans ne remarquent plus : l’indentation est la syntaxe. Dans la plupart des langages, la structure de blocs est marquée par des accolades ou des mots-clés, et l’indentation n’est qu’une décoration dont l’œil humain se sert et que le compilateur ignore. Ce qui signifie que les deux peuvent se contredire. Les accolades peuvent dire une chose pendant que l’indentation en dit une autre, et le code peut sembler faire une chose tout en en exécutant une autre — le classique bug de l’indentation trompeuse, la famille d’erreurs à l’origine du tristement célèbre trou SSL goto fail d’Apple, où une deuxième ligne indentée égarée se trouvait en dehors d’un if qui, visuellement, paraissait la contenir.

Python rend cette catégorie de bug structurellement impossible. L’indentation que vous voyez est la structure de blocs qui s’exécute. Il n’existe aucune seconde vérité cachée dont elle pourrait diverger. Van Rossum a hérité cela d’ABC parce que cela mettait fin aux débats sur l’emplacement des accolades, mais le bénéfice plus profond est précisément son principe : cela rend la lecture honnête. Ce que l’œil du lecteur perçoit comme la forme du programme est, par définition, la forme qu’exécute l’interpréteur.⁴⁵

Cette structure honnête explique aussi pourquoi Python a l’allure qu’il a pour un non-programmeur : celle d’un pseudocode structuré qui, par chance, s’exécute. C’était tout l’objectif. Van Rossum, de son propre aveu très visuel, a conçu la surface pour qu’elle soit accessible et la structure pour qu’elle soit visible, afin que l’écart entre « lire le code » et « comprendre le programme » soit aussi réduit que la grammaire le permet.

Le Zen de Python et la « seule manière évidente »

En 1999, le développeur historique du cœur de Python, Tim Peters, a couché par écrit les valeurs de conception qui animaient Python en vingt aphorismes. Ils ont fini par être consacrés sous le nom de PEP 20, le Zen de Python, et ils sont livrés à l’intérieur même du langage : tapez import this dans une invite Python et ils s’affichent. Le crédit a son importance, et on le donne souvent à tort : c’est Tim Peters qui a écrit le texte, pas van Rossum.² Mais le Zen est une distillation de la sensibilité de conception de Guido — Peters formulait les valeurs qui étaient déjà dans le langage, comme un bon critique formule l’intention d’un artiste mieux que l’artiste lui-même.

Deux lignes portent toute la philosophie. « La lisibilité compte. » Et : « Il devrait y avoir une — et de préférence une seule — manière évidente de le faire. »² Cette deuxième ligne est l’inversion délibérée de la devise célèbre de Perl, « There’s more than one way to do it » (il y a plus d’une façon de le faire). Le Python de van Rossum parie dans l’autre sens : un langage qui n’offre qu’une seule manière évidente est un langage dont le code se ressemble quel que soit son auteur, ce qui veut dire que n’importe qui peut lire le code de n’importe qui d’autre. La convergence vers un idiome unique n’est pas une contrainte pour l’auteur ; c’est un cadeau fait à chaque lecteur futur. (Jusqu’à la ponctuation de l’aphorisme lui-même — les tirets cadratins encadrant « et de préférence une seule » — qui est une plaisanterie discrète sur la règle légèrement transgressée au moment même où on l’énonce.)

BDFL et gouvernance : le retrait de 2018

Pendant la majeure partie de la vie de Python, van Rossum a eu le dernier mot sur la conception du langage, sous un titre forgé à moitié pour rire lors d’un rassemblement Python en 1995 et rendu permanent par Barry Warsaw : BDFL, Benevolent Dictator For Life (dictateur bienveillant à vie).⁷ C’était un véritable modèle de gouvernance. Les évolutions du langage passaient par le processus PEP — les Python Enhancement Proposals, le mécanisme ouvert, écrit et archivé par lequel tout changement est proposé, débattu et tranché — mais quand le consensus échouait, c’était le BDFL qui décidait. Pendant des décennies, cela a fonctionné, parce que c’était au goût de van Rossum que la communauté faisait confiance.

Tout a pris fin à cause d’un seul opérateur. PEP 572 a introduit l’expression d’affectation « walrus » (« morse »), :=, et le débat fut d’une âpreté inhabituelle — van Rossum l’a imposée contre une opposition bruyante et tenace. Le 12 juillet 2018, quelques jours après son adoption, il a publié sur la liste python-committers un courriel intitulé « Transfer of power » (passation de pouvoir). « Maintenant que PEP 572 est bouclée, écrivait-il, je ne veux plus jamais avoir à me battre aussi durement pour une PEP et constater qu’autant de gens méprisent mes décisions. » Il s’est accordé « des vacances permanentes de la fonction de BDFL » et — c’est là le point décisif — a catégoriquement refusé de nommer un successeur (« Je ne vais pas désigner de successeur »), laissant la communauté inventer son propre gouvernement.⁸ Ce qu’elle a fait : un Steering Council élu de cinq membres, ratifié par PEP 8016, gouverne désormais Python. Le dictateur bienveillant a délibérément aboli la dictature.

La portée de Python

Le pari de la lisibilité a produit, par intérêts composés, l’un des plus grands résultats de l’histoire du logiciel. Parce que Python était le langage que les gens pouvaient lire, il est devenu le langage que les gens pouvaient enseigner — c’est aujourd’hui le langage d’initiation dominant dans les universités du monde entier. Parce qu’il était lisible et extensible, il est devenu le ciment du calcul scientifique : NumPy, SciPy, pandas, toute la pile de la science des données. Et parce que cette pile était déjà en Python, la révolution de l’apprentissage profond s’est elle aussi construite en Python — PyTorch, TensorFlow, JAX et la quasi-totalité des modèles dont vous avez entendu parler sont pilotés depuis un langage qu’un programmeur néerlandais a conçu pendant des vacances de Noël pour qu’il soit doux à l’œil humain. Van Rossum lui-même est sorti de sa retraite en 2020 pour rejoindre Microsoft et travailler sur le projet Faster CPython, un effort visant à rendre l’interpréteur environ deux fois plus rapide — un retour, selon ses mots, à ses racines.⁹

La méthode

La méthode tient en une conviction — optimiser pour le lecteur — poursuivie avec une constance peu commune pendant trente-cinq ans.

Optimisez pour l’humain qui lit le code. Pas pour la machine, pas pour l’auteur sur l’instant. Chaque décision de surface — l’indentation, le petit vocabulaire de mots-clés, l’exigence de clarté — sert la personne qui lira la ligne plus tard, parce que c’est elle le public réel et qu’elles sont bien plus nombreuses.¹

Rendez la structure visible et la lecture honnête. L’indentation est la structure de blocs, si bien que ce que l’œil perçoit est ce que l’interpréteur exécute. Le langage refuse de laisser l’apparence du code et son comportement diverger.⁴

Préférez une seule manière évidente. Résistez à la tentation d’offrir cinq idiomes pour la même tâche. La convergence vers un idiome unique et clair fait qu’un code écrit par des inconnus se lit toujours comme s’il avait été écrit d’une seule main.²

Prenez les bonnes idées et corrigez les erreurs. Python, c’est la lisibilité et l’indentation d’ABC, moins la conception monolithique, fermée et inextensible d’ABC. Van Rossum n’a pas inventé à partir de rien ; il a été un éditeur exigeant de ce qui l’avait précédé.⁴⁵

Gouvernez au grand jour, et sachez lâcher prise. Le processus PEP rendait les décisions de conception publiques et écrites. Et lorsque le fait d’être l’autorité ultime est devenu un coût pour la communauté plutôt qu’un service rendu, il s’est retiré — et a refusé d’oindre un remplaçant, forçant une institution durable à se former à sa place.⁸

Chaîne d’influence

Qui l’a façonné

ABC, et Lambert Meertens, Leo Geurts et Steven Pemberton au CWI. ABC a légué à van Rossum ses deux idées fondatrices — l’indentation comme syntaxe et la lisibilité comme objectif premier — et, en échouant, lui a enseigné les leçons négatives : ne construisez pas un monolithe, ne fermez pas la conception, n’ignorez pas le programmeur de terrain. Python, c’est la bonne moitié d’ABC, sauvée. (Influence directe et formatrice)

Modula-3. Sa conception soignée des modules et des exceptions a influencé celle de Python, rappel que van Rossum empruntait délibérément aux langages qu’il admirait plutôt que de réinventer chaque roue. (Influence directe)

C et la culture Unix. C a donné à Python son langage d’implémentation (CPython est écrit en C) et son public cible — les hackers Unix/C qu’ABC n’avait jamais touchés. Python a été conçu pour être la couche de script lisible au-dessus de C, extensible en C, ciment d’un monde en C. (Influence formatrice)

Qui il a façonné

La plus grande communauté de programmeurs au monde. Python est, selon la plupart des mesures, désormais le langage de programmation le plus utilisé au monde, et le premier langage enseigné par défaut aux débutants. Une génération a appris à penser les programmes dans une syntaxe conçue pour être lue.

La science des données, l’IA et le calcul scientifique. NumPy, pandas, PyTorch, TensorFlow — tout l’outillage de l’ère moderne de l’IA repose sur Python parce que Python était le langage que les chercheurs pouvaient lire et étendre. Le pari de la lisibilité est, indirectement, porteur pour le domaine dans lequel je travaille.

La gouvernance de l’open source. Le modèle BDFL, et sa dissolution délibérée en un Steering Council élu, est devenu un modèle étudié de la façon dont un projet guidé par le goût d’une seule personne peut survivre à l’autorité de cette personne.

Le fil conducteur

Yukihiro Matsumoto a conçu Ruby pour le bonheur du programmeur et le principe de moindre surprise ; van Rossum a conçu Python pour le lecteur. Ce sont les deux grands langages de la « joie », et c’est le même instinct visant des cibles légèrement différentes — Matz optimise la sensation qu’on a à écrire, van Rossum celle qu’on a à lire — ce qui explique pourquoi ils convergent si souvent et pourquoi leurs communautés se reconnaissent l’une l’autre. Donald Knuth a atteint la même destination depuis le monde universitaire avec la programmation lettrée : l’affirmation radicale qu’un programme est une œuvre de littérature écrite pour des humains, et que la capacité de la machine à l’exécuter est presque un effet secondaire. Van Rossum a inscrit cette conviction dans la grammaire d’un langage plutôt que dans une méthodologie. Et là où Bjarne Stroustrup a placé la performance à coût nul au premier rang et laissé C++ devenir un langage qu’il faut des années pour lire couramment, van Rossum a placé la lisibilité au premier rang et accepté la lenteur de l’interpréteur comme prix à payer — deux concepteurs, des priorités diamétralement opposées, payant chacun dans la monnaie que l’autre refusait de dépenser. (Pont de la série)

Ce que j’en retiens

La leçon que je retiens, c’est que la lisibilité n’est pas de la politesse ; c’est le produit lui-même. Le code est lu bien plus qu’il n’est écrit, donc la version claire à lire est la version qui vaut le plus — et « je nettoierai plus tard » est une promesse faite à un lecteur que je trahis discrètement dès maintenant. Le geste de van Rossum consiste à faire de la version claire la version par défaut, afin que bien faire soit la voie de moindre résistance plutôt qu’un acte de discipline. C’est exactement la même exigence que la qualité comme seule variable : la question n’est jamais « est-ce que ça tourne ? » mais « est-ce que la prochaine personne qui lira ceci le comprendra aussi vite qu’elle en a besoin ? »

Dans le monde où je construis aujourd’hui — agents, boucles d’outils, prompts, code de cadre d’agent que d’autres agents et mon moi futur liront à 2 h du matin — la tentation est l’inverse de « la lisibilité compte » : des one-liners astucieux, de l’état implicite, cinq façons de faire la même chose éparpillées dans une base de code que personne ne peut tenir entière dans sa tête. Le geste de van Rossum consiste à choisir la seule manière évidente et à rendre la structure honnête, pour que ce que vous lisez soit ce qui s’exécute. Cette conviction — qu’une clarté rendue structurelle et imposée par la grammaire du système plutôt que laissée à la seule volonté produit des intérêts composés chez tous ceux qui la liront ensuite — est le fil conducteur qui relie un projet de loisir de Noël 1989 à un cadre d’agent de 2026. Le lecteur est le public. Construisez pour lui.

FAQ

Quelle est la philosophie d’ingénierie de Guido van Rossum ?

La conviction centrale de van Rossum est que le code est lu bien plus souvent qu’il n’est écrit, et qu’un langage devrait donc être optimisé pour l’humain qui le lit.¹ Il a bâti Python autour de la lisibilité érigée en objectif premier et structurel — non pas une règle de style ajoutée après coup, mais inscrite dans la grammaire par l’indentation significative, un petit vocabulaire de mots-clés et le principe selon lequel il devrait y avoir « une seule manière évidente de le faire ».² Il a associé cela à une gouvernance ouverte du langage à travers le processus PEP, puis, en 2018, à son retrait délibéré de la fonction d’autorité ultime.⁸

Pourquoi Python utilise-t-il l’indentation plutôt que des accolades ?

Van Rossum a repris la structure de blocs fondée sur l’indentation (la « règle du hors-jeu ») du langage ABC, sur lequel il a travaillé au CWI dans les années 1980 ; il appréciait qu’elle mette fin aux interminables disputes sur l’emplacement des accolades.⁴⁵ La raison plus profonde de sa pérennité, c’est qu’elle rend la lecture honnête : dans les langages à accolades, l’indentation est décorative et peut contredire les accolades, si bien qu’un code peut sembler faire une chose tout en en exécutant une autre (le bug de l’indentation trompeuse). Dans Python, l’indentation que vous voyez est la structure de blocs qui s’exécute — il n’existe aucune seconde vérité cachée dont elle pourrait diverger.

Qui a écrit le Zen de Python ?

Tim Peters, développeur de longue date du cœur de Python, a écrit le Zen de Python — les vingt aphorismes consacrés sous le nom de PEP 20 et affichés lorsqu’on exécute import this. Ce n’est pas Guido van Rossum qui l’a écrit, une erreur d’attribution courante.² Ce qu’il fait, c’est distiller les valeurs de conception propres à van Rossum sous une forme mémorable — des formules comme « La lisibilité compte » et « Il devrait y avoir une — et de préférence une seule — manière évidente de le faire » formulent la sensibilité qui était déjà intégrée au langage.

Pourquoi Guido van Rossum a-t-il quitté son rôle de BDFL de Python ?

Van Rossum avait dirigé Python pendant des décennies en tant que BDFL — Benevolent Dictator For Life (dictateur bienveillant à vie), un titre forgé à moitié pour rire lors d’un rassemblement Python en 1995.⁷ Il a démissionné le 12 juillet 2018, quelques jours après l’adoption controversée de PEP 572 (l’opérateur walrus :=), qu’il avait imposée contre une forte opposition. Dans un courriel intitulé « Transfer of power », il écrivait : « Maintenant que PEP 572 est bouclée, je ne veux plus jamais avoir à me battre aussi durement pour une PEP et constater qu’autant de gens méprisent mes décisions », s’est accordé « des vacances permanentes de la fonction de BDFL » et a explicitement refusé de nommer un successeur.⁸ La communauté l’a remplacé par un Steering Council élu de cinq membres.

Sources