On a tous écrit ce bout de code : un booléen found = False déclaré avant la boucle, basculé à True à l’intérieur du if, puis testé après la boucle. Ça fonctionne, mais Python propose une syntaxe native qui rend ce drapeau inutile : le bloc else attaché à une boucle for ou while. Ce mécanisme reste peu utilisé dans le code francophone, alors qu’il simplifie la logique de recherche et de validation.
Le drapeau booléen dans une boucle for Python : le problème concret
Prenons un cas classique. On parcourt une liste d’identifiants pour trouver celui qui correspond à une requête. Le réflexe habituel ressemble à ceci :
A voir aussi : Transfert de Données entre Téléphones : Guide Complet pour Sauvegarder et Partager vos Informations
found = False
for uid in identifiants:
if uid == cible:
found = True
break
if not found:
print("Identifiant absent")
Trois éléments gravitent autour de la même intention : la variable found, le break, et le test if not found après la boucle. On déclare un état, on le mute, on le lit. Pour une recherche simple, c’est verbeux.
A lire également : Python and list dans les boucles : écrire moins, faire plus
Le vrai problème apparaît quand on imbrique plusieurs boucles ou qu’on enchaîne les validations. Chaque drapeau supplémentaire ajoute un état à suivre mentalement. Sur un script de validation d’entrées utilisateur (vérifier qu’aucun champ n’est vide, qu’un format est respecté, qu’une valeur existe dans une base), on se retrouve avec trois ou quatre booléens déclarés en amont. Le code devient difficile à relire, et les bugs liés à un drapeau mal réinitialisé ne sont pas rares.
Syntaxe else sur une boucle for en Python : comment ça marche
Le bloc else d’une boucle s’exécute uniquement si la boucle se termine sans qu’un break ne soit déclenché. Voici le même exemple réécrit :
for uid in identifiants:
if uid == cible:
print("Trouvé")
break
else:
print("Identifiant absent")
Plus de variable intermédiaire. La logique tient en un seul bloc : on cherche, on sort si on trouve, et le else gère le cas « pas trouvé ».
La règle à retenir sur for/else
Le else s’exécute quand la boucle se termine naturellement, sans break. C’est contre-intuitif au premier contact, parce qu’on associe else à if. Ici, il faut le lire comme « si aucune interruption ne s’est produite ».
La même mécanique s’applique à while :
while tentatives < max_essais:
reponse = interroger_service()
if reponse.ok:
traiter(reponse)
break
tentatives += 1
else:
signaler_echec()
Sans else, on aurait eu besoin d’un booléen succes ou d’un test sur le compteur après la boucle.
Cas d’usage où for else remplace efficacement un drapeau
Le motif fonctionne chaque fois que la boucle cherche un élément ou vérifie une condition avec sortie anticipée. Voici les situations où on en tire le plus de bénéfice :
- Recherche d’un élément dans une collection sans recourir à
in(par exemple quand la comparaison est complexe ou qu’un traitement doit s’exécuter au moment de la trouvaille). - Validation séquentielle : on parcourt des règles de validation et on sort dès qu’une règle échoue. Le
elseconfirme que toutes les règles sont passées. - Tentatives de connexion ou de requête avec un nombre limité d’essais. Le
elsegère le cas d’échec total, sans variable supplémentaire. - Vérification de primalité : on teste les diviseurs potentiels, on sort si l’un divise le nombre, et le
elsedéclare le nombre premier.
Sur ces quatre cas, le code passe de trois structures (déclaration, mutation, test) à une seule (for/else).
Un piège fréquent avec les boucles vides
Si la collection itérée est vide, la boucle for ne s’exécute pas du tout. Le bloc else s’exécute quand même, puisqu’aucun break n’a eu lieu. C’est un comportement logique, mais qui surprend quand on s’attend à ce que le else signifie « rien trouvé après avoir cherché ». Sur une liste vide, on n’a pas cherché.
La parade est simple : tester la collection avant la boucle si le cas vide mérite un traitement distinct.
Lisibilité du code Python avec else sur for : retours terrain
La critique la plus courante porte sur la lisibilité. Des développeurs expérimentés jugent la syntaxe for/else confuse parce que le mot else ne communique pas clairement son rôle. Les retours varient sur ce point : dans une équipe habituée à ce pattern, il devient naturel. Dans un projet open source avec des contributeurs de niveaux différents, il peut ralentir la relecture.
En pratique, un commentaire d’une ligne au-dessus du else suffit à lever l’ambiguïté :
for uid in identifiants:
if uid == cible:
break
else: # aucun identifiant ne correspond
lever_erreur()
Ce compromis conserve la concision du pattern sans sacrifier la compréhension.
Quand garder le drapeau booléen
Le for/else ne couvre pas tous les scénarios. Dès que la logique après la boucle dépend de plusieurs états (trouvé et valide, trouvé mais expiré, pas trouvé), un booléen nommé explicitement reste plus clair qu’un empilement de break conditionnels. Le pattern else de boucle brille sur les recherches binaires : trouvé ou pas, validé ou pas, réussi ou pas.
Si on a besoin de conserver l’élément trouvé pour l’utiliser après la boucle, une variable de résultat remplace avantageusement le drapeau. On stocke directement la valeur au lieu d’un booléen, et le else gère le cas par défaut.
Remplacer un drapeau booléen par for/else réduit le nombre de variables d’état et resserre la logique au plus près de la boucle. Le gain n’est pas spectaculaire sur un script de dix lignes, mais sur du code de validation ou de recherche répétée, la différence de lisibilité s’accumule. Tester ce pattern sur un cas réel, le commenter pour l’équipe, et décider ensuite de l’adopter ou non reste la meilleure approche.
