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.
Post intéressant, qui m’amène à me demander : est-ce que ce serait pas plus pratique de prévoir toute une liste de mots-clés réservés à la créa d’un nouveau langage, quitte à ne pas en utiliser certains tout de suite ? Je pense notamment à class en JS, qui a été inutile durant un bon moment et qui va devenir très utilisé dans la norme ES6.
C’est une idée intéressante, mais quelles est la limite ? Comment tu évalues ça ? Si tu en prends trop, tu vas frustrer tes utilisateurs qui voudrons écrire des variables sans pouvoir le faire.
Il faut que ces mots-clés soient en ligne avec leur usage à venir … donc avoir une très bonne idée des features à venir et de comment elles vont être implémentées
C’est sûr que ça implique de se projeter dans le futur et d’anticiper sur les nouvelles tendances, mais rien n’empêcherait de libérer des mots-clé au fur et à mesure qu’on est sûr de ne jamais en avoir besoin. Après ça reste très spéculatif, faudrait voir en action sur le long terme.
Et on créé un marché des mots clés qu’on vend après aux dev. Sinon ils ont droit qu’à une lettre. Bon business model !
Et pourquoi ne pas dire (au moment de la création d’un langage) que tous les mots-clés dudit langage, même ceux qui n’ont pas encore été inventés, auraient un préfixe bien défini ?
Ainsi tout (variables, méthodes, fonctions, classes, …) ce qui serait créé par le développeur et qui commencerait par ce préfixe serait rejeté par le compilateur, même si ça ne crée par de conflit au moment de la compilation. Seul le langage serait ainsi autorisé à faire appel à un nommage utilisant ce préfixe.
Parce que ce serait chiant à lire et à taper :)
Ouais, bonne idée, faudrait préfixer les variables avec
$
comme ça plus de problème !
Enfin, ça serait trop contraignant, personne n’utiliserais plus ce langage… ;·)
J’ai pas dis “personne n’utiliserais plus ce langage “, j’ai dis “Parce que ce serait chiant à lire et à taper “, ce qui est exactement le cas de PHP. J’ai horreur des variables de PHP pour cette raison.
Yocto correction: décénies => décennies
Sinon, l’article est nickel ;-)
Sinon, dans tous les anciens codes, une pitite regex : s/async/async_/g et pouf, c’est réglé pour la transition.
Un changement de version qui se fait en opérant deux regex sur le code à porter, c’est pas tous les jours.
Par contre, ça enlève rien au fait que yaura des emmerdes plus tard.
Pourquoi ne pas utiliser des décorateurs plutôt ? C’est bô et pythonique !
Par contre, je suis impatient de savoir combien de temps vont mettre les modules, plugin, frameworks,… pour implémenter la coloration des deux nouveaux mots-clef.
Parce qu’actuellement, quand du code présente ces fonctionnalités sur le web, j’ai du mal à regarder ça d’un œil partial. Les mot-clefs sont même pas colorés, c’est forcément moche :)
oupa: http://aiju.de/rant/syntaxon.jpg