16.5. Programmation centrée sur les données

Maintenant, vous vous demandez certainement pourquoi tout ça est mieux que d'utiliser des boucle for et de simples appels de fonction. C'est une question tout à fait justifiée. En fait, c'est avant tout une question de perspective, utiliser map et filter vous oblige à centrer votre réflexion sur les données.

Dans le cas présent, nous avons commencé absolument sans données, la première chose que nous avons faite est d'obtenir le chemin du répertoire du script en cours, puis une liste des fichiers de ce répertoire. Cette amorce nous a amené de véritables données avec lesquelles travailler : une liste de noms de fichiers.

Cependant, nous ne nous intéressons pas à tous ces fichiers, seulement à ceux qui sont des suites de tests. Nous avions trop de données, nous avions donc besoin de les filtrer. Comment savoir quelles données conserver ? Nous avions besoins d'un test pour le décider, nous en avons donc créé un que nous avons passé à la fonction filter. Dans le cas présent, nous avons utilisé une expression régulière, mais le concept serait le même quelle que soit la manière dont le test serait constitué.

Nous avions donc les noms de fichiers de chaque suite de tests (et seulement des suites de tests puisque le reste a été filtré), mais ce que nous voulions précisément c'était des noms de modules. Nous avions la quantité de données correcte, mais elles étaient dans un mauvais format. Nous avons donc défini une fonction qui transformerait un nom de fichier en nom de module et l'avons appliquée à toute la liste. D'un nom de fichier, nous obtenons un nom de module, d'une liste de noms de fichiers, une liste de noms de modules.

À la place de filter, nous aurions pu utiliser une boucle for avec une instruction if. Au lieu de map, nous aurions plus utiliser une boucle for avec un appel de fonction. Mais utiliser des boucles de cette manière est un travail de tâcheron. Au mieux, c'est une perte de temps, au pire, on introduit des bogues difficile à détecter. Par exemple, il faut de toute manière définir la condition de test pour «ce fichier est-il une suite de test ?», c'est la logique spécifique de l'application et aucun langage ne va l'écrire à notre place. Mais une fois que l'on a résolu cette question, pourquoi s'épuiser à définir une nouvelle liste vide, écrire une boucle for, une instruction if et appeller manuellement append pour ajouter chaque élément à la nouvelle liste si il répond à la condition et ensuite garder trace de quelle variable contient la nouvelle liste et de celle qui contient l'ancienne ? Pourquoi ne pas nous contenter de définir la condition de test et laisser Python faire le reste du travail pour nous ?

Oh, bien sûr, vous pouvez montrer plus d'astuce et supprimer les éléments en place sans créer de nouvelle liste. Mais cela vous a déjà joué des tours. Essayer de modifier une structure de données que vous êtes en train de parcourir peut être périlleux. Vous supprimez un élément, bouclez sur le suivant et voilà que vous en avez sauté un. Est-ce que Python fait partie des langages qui fonctionnent de cette manière ? Combien de temps vous faudrait-il pour le découvrir ? Et est-ce que vous vous rappellerez si c'est sûr la prochaine fois que vous essayerez ? Les programmeurs passent tellement de temps et avec tellement d'erreurs, à se préoccuper de problème purement techniques de cet ordre, tout cela est inutile. Cela n'avance en rien votre programme, ce n'est que du travail de tâcheron.

J'étais réticent aux list comprehensions quand j'ai appris Python et j'ai résisté à filter et map encore plus longtemps. Je tenais à me rendre la vie plus difficile en me cantonnant à la manière familière des boucles for et des instructions if, à la programmation pas à pas, centrée sur le code. Et mes programmes Python ressemblaient beaucoup à des programmes Visual Basic, détaillant chaque étape de chaque opération dans chaque fonction. Et ils avaient tous les mêmes petits problèmes et les mêmes bogues difficiles à détecter. Et tout cela était inutile.

Laissons tout cela derrière nous. Le code de tâcheron n'est pas important. Les données sont importantes et les données ne sont pas compliquées. Ce ne sont que des données, s'il y en a trop, filtrez-les, si elles ne sont pas au bon format, transformez-les. Concentrez-vous sur les données, abandonnez le travail de tâcheron.