3,3333333333335. Voilà le nombre que Python m'a craché en pleine figure le soir où je voulais simplement répartir huit parts de tarte entre trois personnes, un calcul qu'une élève de primaire ferait de tête. Après deux ans d'apprentissage autonome de Python, je sais aujourd'hui pourquoi ce genre de résultat déboussole autant de débutantes : il existe deux familles d'opérateurs mathématiques pour diviser, et confondre l'une avec l'autre transforme un exercice tout bête en soirée de nerfs.
Les opérateurs mathématiques ne se résument pas à un seul geste
Longtemps, j'ai essayé de mémoriser bêtement lequel des sept symboles faisait quoi, une liste de vocabulaire à réciter avant un contrôle. Ça n'a jamais marché : dès que je refermais le carnet, l'ordre se mélangeait, et le lendemain je retapais un slash simple là où il fallait une double barre. Ce qui a fini par tenir, c'est autre chose, comparer deux situations concrètes plutôt que deux symboles abstraits. Diviser une quantité qu'on veut répartir à la miette près n'a rien à voir avec diviser un total en lots complets, même si les deux calculs se ressemblent sur le papier.
Cette formation python que j'ai fini par choisir pour progresser après le travail, je la mène seule, sans professeur pour m'arrêter avant la fausse route, et les opérateurs mathématiques ont fini par devenir mon premier vrai test de logique autonome. Avant de m'arrêter sur Python, j'avais hésité avec JavaScript, un carrefour que j'ai laissé derrière moi sans jamais regretter.
Prenez une recette pensée pour quatre personnes qu'il faut adapter à trois convives. Multiplier chaque quantité par trois puis diviser par quatre donne un résultat exploitable, même avec des décimales : le compte reste juste. Le même réflexe appliqué à un nombre de parts entières, combien de boîtes de six œufs il faut acheter pour en avoir quinze, donne un résultat absurde si on garde les décimales. C'est exactement la différence entre les deux opérateurs de division en Python, et c'est ce qui a fini par rendre tout le reste évident.
Le slash classique et ses virgules interminables
Le slash simple, ce / qu'on utilise depuis l'école primaire, garde toute la précision du calcul. Tapez 7 / 2 et Python répond 3.5, sans arrondir, sans couper la poire en deux à sa manière. Depuis la version 3 du langage, ce comportement est systématique : une division classique renvoie toujours un nombre à virgule, même quand le compte tombe juste. Pour une moyenne de notes, pour un dosage de recette, pour tout ce qui doit rester fidèle au réel, c'est exactement l'outil qu'il faut.
Avant même de m'en apercevoir, j'affectais déjà des valeurs à des variables avec un simple signe égal, un geste qui n'a rien à voir avec une équation malgré les apparences, et qui a précédé de loin ma rencontre avec les opérateurs mathématiques proprement dits. Installer Python sur mon ordinateur, à l'époque, m'avait déjà semblé une montagne, alors les subtilités entre / et // auraient achevé n'importe quelle débutante pressée.
Le rôle du modulo
Gaultier, mon voisin de palier, croisé un soir dans l'escalier pendant que je ruminais une histoire de division entière, a une manie : il ne répond jamais directement à une question technique, il en pose deux autres. Ce soir-là, à ma question sur le modulo, il m'a demandé ce que je voulais garder du calcul, le nombre de fois où ça rentre, ou ce qu'il reste après. La réponse était dans la question.
Le reste, justement, c'est tout l'intérêt du symbole %. Il ne calcule aucun pourcentage, contrairement à ce que sa forme laisse penser : il renvoie ce qui reste après une division entière. Avec 70 minutes à convertir, 70 // 60 donne une heure pleine et 70 % 60 donne les dix minutes qui restent, la double barre garde le nombre d'unités complètes, le pourcentage récupère la miette qui traîne derrière. C'est la même logique que ranger des œufs par boîtes de six : la division entière dit combien de boîtes sont pleines, le modulo dit combien d'œufs restent posés à côté, sans boîte.
Un modulo qui tombe à zéro, glissé dans un if, donne une condition de parité toute prête, et la même logique me sert à naviguer dans une liste sans dépasser sa taille, une histoire d'index qui m'a longtemps semblé être de la magie noire. Les boucles for et while, elles, ont leur propre façon de compter, qui recoupe parfois le modulo : un cycle qui revient à zéro tous les sept tours sent immédiatement le %.
L'autre soir, j'ai rouvert un vieux fichier .py complètement oublié, un brouillon abandonné après une séance ratée, et j'ai compris chaque ligne sans aide, divisions, modulos, tout y était clair, alors que ces mêmes lignes m'auraient semblé du chinois plus tôt dans mon apprentissage.
Gwilherm, un pair autodidacte que je croise régulièrement en ligne, compare toujours le débogage à une panne mécanique : chercher la pièce défaillante plutôt que maudire le moteur. C'est ce qu'il m'a répondu quand je me suis plainte d'une ZeroDivisionError, encore un message d'erreur parmi tant d'autres que j'ai appris à déchiffrer un par un, qui plantait tout mon script à cause d'un cas que je n'avais pas prévu. Depuis, j'ai commencé à regarder comment utiliser try except en Python pour éviter que ce genre de bug ne bloque tout le programme, une manière d'anticiper la pièce qui va lâcher avant qu'elle ne lâche.
Choisir le bon opérateur selon ce qu'on compte
Voilà où j'en suis, après avoir longtemps confondu tous ces symboles : le slash simple pour tout ce qui doit rester précis, la double barre et le modulo pour tout ce qui se compte par lots ou par cycles, et la double étoile ** pour les puissances, le petit chapeau ^, lui, ne sert à rien de tel en Python, c'est un piège classique pour qui vient d'une calculatrice.
Les fonctions simples m'ont appris à ne plus recopier le même calcul trois fois dans le même script, les dictionnaires clé-valeur me servent à ranger un résultat juste après l'avoir calculé, et les chaînes de caractères m'ont montré que le signe + change complètement de sens dès qu'il ne s'agit plus de chiffres : additionner deux nombres et coller deux mots n'ont rien en commun, sinon le symbole.
Je n'ai jamais eu besoin d'importer le moindre module pour tout ça, ces opérateurs sont natifs au langage, disponibles dès la première ligne. Récupérer un nombre tapé par un utilisateur avec input() demande en revanche une conversion explicite avant de pouvoir diviser quoi que ce soit, sans quoi Python refuse tout net. Et les erreurs d'indentation, elles, n'ont jamais rien eu à voir avec le calcul : c'est un tout autre combat, mené sur un tout autre front.
Le radiateur du couloir a fini par se manifester, ce claquement sourd qu'il fait presque tous les soirs vers cette heure-là quand il se remet en route, et c'est mon signal habituel pour refermer l'ordinateur. La prochaine étape, ce sera sans doute d'aller voir comment utiliser le module random en Python pour construire un premier petit jeu, question de voir si mes opérateurs tout neufs survivent à un peu de hasard. Pour l'instant, je garde cette certitude toute simple : le bon opérateur n'est jamais qu'une question de ce qu'on cherche à garder, le tout, la part entière, ou ce qu'il en reste.