Syntaxe Python : indentation, lignes, deux-points et les règles qui comptent

Le plus petit règlement possible

Python a la réputation d'être lisible, et ça tient surtout au peu de règles de syntaxe que le langage possède vraiment. Tu peux faire tenir celles qui comptent sur une seule page :

• Une instruction par ligne.
• L'indentation définit la structure — pas d'accolades, pas de mot-clé end.
• La casse compte. name et Name sont différents.
• : ouvre un bloc ; les lignes suivantes, indentées dessous, sont le corps du bloc.
• # commence un commentaire.

C'est à peu près tout. Tout le reste, ce sont des variables, des fonctions et des habitudes de la bibliothèque standard, que tu ramasseras au fur et à mesure. Passons en revue ces cinq règles avec assez de contexte pour qu'elles cessent d'avoir l'air de règles et commencent à ressembler à la forme naturelle du langage.

Une instruction par ligne

Une instruction est une consigne complète — « affiche ceci », « additionne ça », « assigne cela ». En Python, chaque instruction va sur sa propre ligne :

Trois instructions, trois lignes. Tu n'as pas besoin de point-virgule à la fin, et la plupart du code Python n'en utilise pas. (Tu peux mettre deux instructions sur une ligne avec un point-virgule, mais c'est considéré comme du mauvais style. À éviter.)

Si une ligne a vraiment besoin d'être longue, tu peux la couper à un point naturel à l'intérieur de parenthèses, crochets ou accolades — Python ne se plaindra pas :

Ou, moins couramment, termine une ligne par une barre oblique inverse pour la continuer. Préfère l'astuce des parenthèses quand tu peux — c'est ce que la plupart des bases de code utilisent.

L'indentation est structurelle

Voici la partie qui fait trébucher les nouveaux venus. En Python, les espaces au début d'une ligne ont un sens. Ils disent à Python quelles lignes vont ensemble.

Regarde un simple if :

Les deux lignes après if hour < 12: sont indentées de quatre espaces. Python lit cette indentation comme « ces deux lignes sont le corps du if ». Le dernier print est revenu à la marge de gauche, donc Python le voit comme en dehors du if.

Si tu retires l'indentation, le if casse. Si tu sur-indentes d'un espace de trop, le if casse. Python est strict ici parce que l'indentation est la structure — il n'y a pas de { ni de end pour l'appuyer.

Quelques règles qui en découlent :

1. Choisis quatre espaces par niveau d'indentation et tiens-t'y. C'est la convention PEP 8 et ce que chaque éditeur utilise par défaut pour les fichiers .py.
2. Ne mélange pas tabulations et espaces. Python 3 rejette un fichier qui utilise les deux. Les éditeurs modernes convertissent automatiquement les tabulations en espaces à l'enregistrement ; assure-toi que le tien est configuré comme ça.
3. Les erreurs d'indentation vont arriver. Quand elles arrivent, le message d'erreur te donne le numéro de ligne. Va vérifier que l'espacement du début de cette ligne est le même que celui de ses voisines.

Le deux-points ouvre un bloc

Chaque construction qui crée un bloc imbriqué — if, else, for, while, def, class, with, try — termine sa ligne d'en-tête par un deux-points. Les lignes suivantes, indentées, forment le corps du bloc :

Deux choses à remarquer : le deux-points à la fin de l'en-tête, et l'indentation de quatre espaces sur les lignes du corps. Si tu oublies le deux-points, Python te dira quelque chose comme SyntaxError: expected ':'. Cette erreur est sans ambiguïté — corrige la ponctuation manquante et c'est bon.

Sensibilité à la casse

Python traite Name, name et NAME comme trois choses entièrement distinctes. Ça s'applique à :

• Tes propres variables et fonctions.
• Les fonctions intégrées comme print, len, True, False, None.
• Les noms de modules et d'attributs.

Ça ne te mord généralement que quand tu mets une majuscule par accident. True est la valeur booléenne vraie ; true est une variable non définie qui lève NameError. Print(...) n'est pas la fonction print — c'est une faute de frappe.

Si une erreur dit « name 'X' is not defined » et que tu jures l'avoir définie, vérifie d'abord la capitalisation. C'est ça neuf fois sur dix.

Les commentaires avec #

Tout ce qui se trouve après # sur une ligne est un commentaire — Python l'ignore complètement. Les commentaires servent à laisser des notes pour les futurs lecteurs (toi compris, dans six mois) :

Python n'a pas de syntaxe de commentaire multiligne. Si tu as besoin de plusieurs lignes, utilise plusieurs lignes #. (Tu verras parfois des chaînes à triple guillemets utilisées comme pseudo-commentaires — c'est une autre chose appelée docstring, on en reparlera quand on abordera les fonctions.)

Mots réservés

Quelques mots sont hors limites comme noms de variables parce que Python les utilise lui-même : if, else, for, while, def, class, return, import, from, as, pass, break, continue, True, False, None, and, or, not, in, is, lambda, try, except, finally, raise, with, yield, global, nonlocal, async, await. Pas besoin de mémoriser cette liste. Si tu essaies d'en utiliser un, Python se plaindra immédiatement.

Tu en sais assez pour lire n'importe quel fichier Python

Chaque règle que tu viens de lire s'applique à chaque fichier Python — un script de deux lignes comme un projet de cent mille lignes. Le reste du langage est construit sur ces cinq idées. Si un fichier a l'air confus, la solution consiste presque toujours à prêter attention à l'indentation en premier. L'indentation te dit ce que fait le code, même avant que tu lises ce que disent les lignes.

Ensuite : les commentaires, un peu plus en profondeur — plus les docstrings, qui sont la façon dont Python gère la documentation pour les fonctions et les modules.