PROJET AUTOBLOG


Sam & Max: Python, Django, Git et du cul

Site original : Sam & Max: Python, Django, Git et du cul

⇐ retour index

Pourquoi il est difficile de “juste ajouter un nouveau mot clé” 11

samedi 16 mai 2015 à 09:52

Avec les types hints, beaucoup ont suggéré l’ajout de nouveaux mots clés pour déclarer les types des paramètres et des variables. Guido a refusé, au moins pour les paramètres des fonctions, et s’en tient aux annotations.

Mais pourquoi être si têtu ? Après tout, c’est forward compatible, n’est-ce pas ?

Faux.

Quand on rajoute un mot clé, on ne peut plus l’utiliser comme nom de variable, et donc tout code qui utilise une variable qui porte ce nom va planter quand il passera à cette version de Python.

Inutile de dire qu’un mot clé doit être court et explicite, et que tous les mots courts et explicites sont utilisés comme noms de variables quelque part.

C’est pour cette raison que l’ajout de async/await a lancé toute une discussion sur la manière de changer la grammaire.

Et vous savez ce qui a été décidé ?

De ne PAS interdire de faire :

async = await = True
async def foo():
    await bar
# pas de SyntaxError

En clair, le parseur va détecter des cas particuliers pour ces instructions dans lesquelles il les identifie comme mot clés, et autoriser quand même leur usage comme variable dans tous les autres cas.

C’est un compromis pour garder la compatibilité ascendante, mais un compromis qui non seulement introduit un cas particulier dans le code du parseur (beurk), mais en plus permet d’écrire un code qui avant n’était pas permis, rendant le langage un peu moins cohérent. Un changement que maintenant on va se trainer pour les releases à venir, qui ouvre un précédent pour les futures débats, qui peut potentiellement s’accumuler avec d’autres changement futurs…

Faire évoluer un langage qui a 20 ans et dont il y a des millions de lignes de code partout, c’est dur. Chaque petite modification peut entrainer des conséquences importantes, et tout juste milieu renferme des craquelures d’inélégance.

C’est aussi pour ça qu’il est si plaisant d’inventer son langage, son framework, son outil pour faire x mieux que le status quo y. Il est parfait. Il est tout frais. Personne ne l’utilise. Il n’a encore eu aucune cicatrice.

A l’inverse, garder le cap malgré les remous, maintenir une diète saine et un équilibre mais accepter les saloperies qui passent de temps en temps, ça c’est difficile. Je suis épaté que Python soit resté si propre avec tout ce qui lui est arrivé au fil des années, et c’est grâce Guido qui a su dire NON à tout un tas de petits détails qui ne paraissaient pas importants, mais qui cumulés sur 2 décennies auraient transformé le langage en créature fantasque.

Pourvu qu’ça dure.