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.