Mon menu réaffiche la même question trois fois de suite avant que je comprenne enfin où se cache le problème. C'est ce genre de petit blocage qui rythme mes soirées de python débutante, penchée sur un menu interactif censé tourner sans se figer ni s'emballer. Cette fois, le nœud du problème n'était pas la boucle while elle-même, mais la façon de lui donner une sortie propre.
Avant de continuer, une précision qui compte : ce carnet contient des liens affiliés, dont celui vers la Formation au langage Python que je suis en ce moment. Si vous achetez via ces liens, je touche une petite commission, sans supplément pour vous. Je ne mets ici que ce qui m'a réellement servi, pas une liste de recommandations écrites pour la forme.
En rentrant des Halles Saint-Joseph l'autre soir, les bras chargés, je me suis surprise à retourner cette question dans ma tête pendant tout le trajet : pour empêcher un menu de se bloquer, vaut-il mieux un interrupteur qu'on éteint soi-même, ou une sortie de secours qui coupe tout d'un coup ? Avant d'avoir un menu qui tienne la route, j'avais essayé de lire la documentation officielle sur les boucles, sans un seul exemple concret ouvert à côté pour m'accrocher, et je n'en gardais que des phrases qui ne voulaient plus rien dire une fois l'écran éteint. Il m'a fallu construire le menu moi-même, avec ses ratés, pour que la mécanique tienne enfin debout.
Deux façons de fermer la porte d'un menu interactif qui tourne
La première façon, c'est l'interrupteur. On pose une variable, disons continuer = True, et la boucle while continuer: tourne tant que cette variable n'a pas changé d'état. Quand l'utilisateur choisit de partir, on écrit continuer = False, et au tour suivant, la boucle referme la porte d'elle-même. C'est un peu comme laisser un mot sur le frigo pour toute la famille : 'on relance une machine tant que le panier n'est pas vide'. Tout le monde vérifie le mot avant de recommencer une lessive.
Break, à l'inverse, ne pose aucune variable de ce genre. On écrit carrément while True:, une boucle qui n'a par elle-même aucune raison de s'arrêter, et on glisse le mot break au milieu du bloc, exactement là où l'utilisateur tape '3' pour quitter. Ça ressemble davantage à un dîner de famille où quelqu'un se lève d'un coup et annonce que la soirée est terminée, sans avoir prévenu personne par un petit mot au préalable. Rien à vérifier avant : la sortie se déclenche là où elle se trouve, et nulle part ailleurs.
Choisir entre l'interrupteur et la sortie de secours
Gaultier, mon voisin de palier, tranche ce genre de question avec une aisance tranquille qui me rassure autant qu'elle m'intimide : pour lui, entre les deux, il n'y a même pas vraiment débat, tout dépend de ce qu'on construit derrière. Sur mon menu à trois choix, break gagne en clarté : on voit tout de suite, dans le bloc concerné, où et pourquoi le programme s'arrête. Mais dès que le menu grossit un peu, avec plusieurs sorties possibles ou une suite de if et de else qui trie des cas différents, l'interrupteur garde l'avantage : la condition de la boucle reste lisible d'un coup d'œil, tout en haut, sans qu'on ait à fouiller chaque bloc pour deviner où le programme peut s'échapper.
Gwilherm, un pair autodidacte que je croise de temps en temps en ligne, construit toujours son code autour d'un projet bien précis plutôt que par principe général, et ça me pousse à me demander laquelle des deux méthodes sert vraiment mon propre menu, pas celle qui sonne le mieux dans un tutoriel. Sa question m'a forcée à tester les deux versions sur le même petit programme, au lieu d'en garder une par simple habitude.
L'interrupteur rassure, la sortie de secours va plus vite
L'appel à input reste, dans les deux méthodes, ce qui met le script en pause le temps que je tape une réponse, et c'est ce petit temps d'arrêt qui donne au menu son air interactif plutôt que de tourner tout seul dans le vide. Le lendemain d'une de ces soirées passées sur ce menu, une collègue m'a montré une formule Excel qui refusait obstinément de se comporter, et je me suis entendue lui expliquer, presque malgré moi, que sa formule ne faisait sa tâche que tant qu'une condition restait vraie, exactement comme mes boucles du soir.
Avec l'interrupteur, chaque tour de boucle repose sur une seule valeur booléenne, vraie ou fausse, et cette lisibilité a un prix : il faut penser à mettre à jour la variable à chaque endroit qui pourrait déclencher une sortie, sinon la porte reste coincée. C'est là que j'ai vécu ma propre version de la boucle qui ne s'arrête plus : une condition mal placée, et le menu s'est mis à réafficher le même choix à une vitesse folle, le ventilateur de mon ordinateur se remettant à ronfler juste après ma deuxième tisane, comme s'il commentait mon erreur. Avec break, ce risque existe moins puisque la sortie est écrite au moment exact où elle doit agir, mais elle devient plus difficile à repérer si le menu s'allonge et que plusieurs break finissent éparpillés dans le code.
Choisir sans se tromper de soirée
Pour un menu court, deux ou trois choix, une seule sortie possible, je prends break sans hésiter : c'est direct, et je vois tout de suite où le programme s'arrête. Dès que le menu s'étoffe, avec plusieurs façons de quitter ou une logique qui dépend de plusieurs conditions à la fois, je passe à l'interrupteur, parce qu'une seule variable en haut de la boucle vaut mieux que des sorties disséminées un peu partout dans le bloc. Ce n'est pas une règle universelle, juste celle qui m'évite de perdre une soirée à chercher pourquoi mon programme refuse de s'arrêter, ou pire, refuse de continuer.
Depuis que Python est installé sur mon ordinateur, chaque nouveau menu me pousse un peu plus loin que le précédent. Je commence à isoler certains bouts de code dans une fonction plutôt que de recopier les mêmes lignes trois fois, et je range désormais mes articles dans une liste plutôt que dans des variables séparées, chacun accessible par son index. La prochaine étape, je crois, c'est de ranger mes choix de menu dans un dictionnaire, une clé pour chaque option, plutôt que d'empiler des if et des else qui s'allongent à chaque nouvelle fonctionnalité. Si vous voulez pousser cette logique de boucle un peu plus loin, jetez un œil à comment utiliser le module random en python pour créer son premier jeu : c'est le jour où j'ai importé mon tout premier module que ce genre de menu a commencé à ressembler à autre chose qu'un exercice.
Il reste des messages d'erreur qui m'arrêtent net, en particulier quand j'oublie l'indentation sous le while ou que je confonds une chaîne de caractères avec le nombre qu'elle est censée contenir. Pour ces moments-là, j'ai fini par regarder comment utiliser try except python pour éviter les bugs, histoire que mon menu ne s'écroule pas juste parce qu'un utilisateur, moi la première, tape autre chose qu'un chiffre. Je pense aussi, un de ces soirs, installer une première bibliothèque avec pip, et peut-être apprendre à lire ce menu depuis un fichier texte au lieu de le taper en dur à chaque fois, tant que ma variable interrupteur reste bien dans sa portée et ne se mélange pas avec celle d'une fonction voisine.
Ce menu ne changera la vie de personne, mais il tourne, il s'arrête quand je le lui demande, et il ne s'arrête pas quand je ne le lui demande pas, ce qui, pour une python débutante qui apprend le soir, ressemble déjà beaucoup à une victoire. Si l'envie de structurer tout ça sérieusement vous prend, la Formation au langage Python reste celle où j'ai puisé la patience de comparer ces deux façons de faire avant de choisir la mienne.