
Une chaîne de caractères ne se laisse jamais corriger de l'intérieur, pas même une seule lettre, même quand on est certaine d'avoir raison. C'est l'un des premiers pièges pour qui démarre une autoformation informatique en Python : on imagine du texte comme un mot qu'on pourrait gratter et réécrire, alors qu'une chaîne de caractères fonctionne plutôt comme un ruban qu'on ne peut que remplacer en entier. Ce carnet reprend les idées fausses qui m'ont fait perdre le plus de soirées en tant que débutante en Python, et ce qu'il faut comprendre à la place.
Avant d'aller plus loin, une précision qui revient dans chacun de mes carnets : certains liens ci-dessous sont affiliés, ce qui veut dire qu'une petite commission peut me revenir si vous cliquez, sans que le prix change pour vous. Je ne cite que ce qui m'a vraiment servi, comme la Formation au langage Python, celle par laquelle j'ai commencé.
Une chaîne de caractères n'est pas qu'un mot tapé au clavier
Longtemps, j'ai cru qu'écrire du texte en Python revenait à taper des mots, un point c'est tout. Sauf que pour l'ordinateur, un mot n'a rien de magique : c'est une chaîne de caractères, une suite de symboles rangés dans un ordre précis, entre guillemets. Ça commence dès qu'on range ce texte dans une variable : sans les guillemets pour délimiter le début et la fin, Python ne sait même pas où votre phrase commence.
Le deuxième malentendu, c'est de croire qu'un seul type de guillemet existe. On a le choix entre les simples et les doubles, et ce choix n'est pas cosmétique : il sert surtout quand la phrase contient elle-même une apostrophe. La règle que j'applique maintenant, plutôt que de m'énerver : si le texte contient une apostrophe, je bascule direct sur les doubles guillemets, et je vérifie que chaque ouverture a bien sa fermeture avant de lancer quoi que ce soit.

En Python, on compte à partir de zéro
Non, et ça m'a pris un moment à digérer. En Python, le premier caractère d'une chaîne porte l'index zéro, pas un. Ça fonctionne exactement comme pour une liste : le tout premier élément se compte à zéro, pas à un, un peu comme si en tricot le premier rang qu'on pose ne comptait pour rien dans la numérotation du rang suivant. Sur le moment, ça paraît absurde. Après quelques essais, ça devient juste une habitude à prendre.
La règle qui me sert désormais pour ne plus me tromper : pour attraper la dernière lettre d'un mot, je ne recompte pas depuis le début, je pars de la fin avec un index négatif. C'est ce détail qui m'a permis d'extraire les premières lettres d'un prénom sans passer par des essais ratés à répétition. Un dernier point que je découvre à peine : ça marche aussi en boucle, tant que l'indentation du bloc reste alignée, la boucle parcourt chaque lettre l'une après l'autre sans broncher.
Le réflexe de corriger une lettre à la main
Quand on découvre l'indexation, on se dit forcément qu'on va pouvoir remplacer une lettre directement, comme on corrigerait une faute au crayon. Python refuse net : une chaîne est immuable, impossible de la modifier une fois créée. C'est un peu comme une pâte déjà cuite: on ne retire pas un ingrédient après coup, il faut refaire la recette depuis le début, même pour changer un seul détail.
Il y a eu ce soir où j'ai refusé de refermer l'ordinateur tant que je n'avais pas trouvé pourquoi ma phrase s'affichait tronquée : j'ai retourné chaque guillemet dans ma tête jusqu'à ce que l'erreur me saute enfin aux yeux. La solution tenait en une ligne — recomposer une chaîne neuve à partir d'un bout de l'ancienne — mais il m'a fallu tout ce temps-là pour l'admettre plutôt que de chercher un raccourci qui n'existe pas.
On ne colle pas un chiffre à du texte avec un simple plus
Autre mythe tenace : additionner du texte et un nombre comme on empile deux ingrédients dans un même saladier. Python n'est pas d'accord, et il le fait savoir avec un message qui revenait sans cesse chez moi : TypeError: can only concatenate str (not "int") to str. C'est le signal qu'on essaie de mélanger deux natures différentes sans les convertir d'abord. Ce qui a tout changé : dès qu'un nombre doit apparaître dans une phrase, je passe systématiquement par une f-string plutôt que par le plus. On glisse un petit f devant les guillemets, on met la variable entre accolades, et tout se range sans forcer.
Ce genre de vérification, j'ai fini par le ranger dans une petite fonction, pour ne pas retaper le même bout de code à chaque script. Je m'en sers aussi dans mes conditions, pour vérifier si un mot commence par une majuscule avant de continuer, et dès que je demande une information à l'utilisateur au clavier, c'est encore une chaîne qui atterrit dans la variable, même quand elle ressemble à un nombre. Si vous voulez voir comment je m'emmêle avec d'autres structures, j'ai aussi écrit sur comment utiliser les dictionnaires en Python sans perdre le fil. Un jour il faudra aussi que j'apprenne à intercepter proprement ce genre d'erreur avec un vrai filet de sécurité dans le code, mais je n'en suis pas encore là.

La syntaxe apprise par cœur, un mythe tenace
Pendant un moment, j'ai tenté d'apprendre par cœur une liste de syntaxes trouvée je ne sais plus où, en me disant que la logique suivrait toute seule derrière. Ça n'a pas marché : je savais réciter la formule sans comprendre pourquoi elle fonctionnait, et au moindre changement de contexte je repartais de zéro, incapable d'adapter quoi que ce soit.
Mon voisin de palier, Gaultier, préfère que je cherche seule avant de sonner chez lui, et il le dit sans détour à chaque fois. Après une sortie dans le quartier Montferrand pour changer d'air, je suis revenue avec une autre idée : arrêter de mémoriser des formules et me demander, à chaque ligne, ce que fait réellement l'ordinateur, dans quel ordre, avec quelle valeur en main. Ça prend plus de temps sur le moment, mais ça reste ensuite.
Quand il faut plus qu'une boucle
Gwilherm, croisé sur un forum en pleine discussion sur les boucles for, m'a raconté qu'avec les relevés de ses machines, une simple boucle ne suffit plus : il lui faut des expressions régulières, importer un module dédié, et des outils comme Pandas pour ne pas y passer la nuit entière. Il m'a expliqué tout ça sans jamais me faire sentir en retard sur quoi que ce soit, alors qu'il aurait eu de quoi.
Pour moi qui trie encore mes petites listes du quotidien, c'est un peu comme comparer une cuisine de particulier à une cuisine de cantine : les outils changent d'échelle, pas la logique de départ. En attendant d'en avoir besoin, je me contente de .upper() pour les majuscules et de .replace() pour corriger une faute de frappe partout dans un texte.

Corriger ces mythes ne rend pas le code plus simple, juste plus clair
Aucun de ces mythes ne disparaît d'un coup : on les recroise sous une autre forme dès qu'on touche à une nouvelle structure. Ce qui change, c'est la question qu'on se pose face à l'erreur — plus "pourquoi ça ne marche pas comme je pensais", et davantage "qu'est-ce que Python fait vraiment ici, et pourquoi".
Si cette manie de corriger les mythes un par un vous parle, la Formation au langage Python [Mon point de départ] reste ce qui m'a évité d'abandonner dans les premiers jours, en remettant de l'ordre dans tout ce que je viens de raconter. Et si un jour le texte pur vous lasse, j'ai aussi un œil sur la Formation Cisco [Pour plus tard], parce que comprendre comment les machines se parlent entre elles m'intrigue, même si ce n'est pas pour tout de suite.
Reste une question que je n'ai toujours pas tranchée : combien de mythes pareils je traîne encore sans le savoir ?