Définition
Vous voulez juste vérifier une chose : ce que renvoie une méthode, la valeur d'une expression, l'orthographe exacte d'un mot clé. Ouvrir un fichier pour ça, l'enregistrer, puis le lancer, prend largement plus de temps que la question elle-même. C'est exactement ce problème que le REPL résout.
Le REPL est l'invite interactive de Python. Vous tapez une ligne, elle s'exécute aussitôt, et le résultat s'affiche sans qu'il faille rien demander de plus. Le sigle nomme la boucle qui tourne derrière : lire ce que vous avez tapé, l'évaluer, afficher le résultat, puis recommencer. On l'ouvre en lançant l'interpréteur sans lui donner de fichier à exécuter, et on le reconnaît du premier coup d'œil à son invite en trois chevrons.
pythonUne fois dedans, deux essais suffisent à voir ce que ça donne concrètement.
>>> 3 * 7
21
>>> "a,b,c".split(",")
['a', 'b', 'c']Vous n'avez appelé print nulle part, et pourtant chaque résultat s'affiche : c'est le REPL lui-même qui l'imprime, pas votre code. Il ne l'affiche d'ailleurs pas comme le ferait un print, puisqu'il passe la valeur par repr, la représentation pensée pour un développeur plutôt que pour un lecteur final. C'est ce qui explique que la chaîne apparaisse ici entourée de ses guillemets : un print l'aurait affichée nue.
Ce qu'il vous évite
Vous voulez savoir ce que split renvoie exactement sur une chaîne qui se termine par une virgule. Sans le REPL, il faut ouvrir un fichier, écrire un print, enregistrer, lancer le script, lire la sortie, puis tout recommencer pour la question suivante. Le REPL ramène ce cycle entier à une ligne tapée et une touche Entrée.
Ce qu'il remplace concrètement, c'est le fichier test.py que presque tout le monde finit par créer à la racine du projet, rempli de brouillons et jamais nettoyé. Ce qu'il ne remplace pas, c'est le fichier lui-même. Un essai ponctuel n'a aucune raison de survivre à la question qu'il a réglée ; un morceau de logique que vous voudrez revoir demain, si.
Le tableau suivant met les deux mondes côte à côte, pour les situations où l'un l'emporte franchement sur l'autre.
| Ce que vous faites | Dans le REPL | Dans un fichier |
|---|---|---|
| Rejouer le même code demain | Il a disparu à la fermeture | Une commande suffit |
| Corriger une ligne d'un bloc | Le bloc entier est à retaper | On édite, on relance |
| Montrer ce code à quelqu'un | Un copier-coller de session | Un fichier versionné |
| Essayer une idée en dix secondes | C'est exactement son terrain | Trois étapes de trop |
Les trois usages qui valent le détour
Le premier est la vérification d'un comportement dont vous n'êtes pas certain. Cette méthode renvoie-t-elle une nouvelle valeur, ou modifie-t-elle l'objet sur place ? Une recherche dans la documentation donne la réponse en théorie, trois secondes d'essai la donnent en pratique.
Le deuxième est l'inspection. type(objet) donne sa nature, dir(objet) la liste de ce qu'il sait faire, et help(objet) affiche sa documentation sans quitter le terminal. Face à une bibliothèque inconnue, ces trois commandes remplacent souvent la lecture complète d'un manuel.
Le troisième est le contrôle d'une installation. Après un pip install, une ligne d'import dans le REPL dit immédiatement si la bibliothèque est bien arrivée dans l'interpréteur qui répond, ce qui n'est pas toujours celui que vous croyez utiliser. Une ModuleNotFoundError à cet instant précis signale presque toujours un environnement virtuel oublié, plutôt qu'un vrai problème d'installation.
Autre avantage, plus discret : une erreur levée ici affiche un traceback de deux lignes au lieu de vingt. Isolée du reste du programme, elle devient nettement plus facile à lire.
L'erreur classique, et le pont vers les fichiers
L'erreur des débuts consiste à écrire un vrai programme dans le REPL, parce que ça avance bien au début. Au bout de quarante lignes, une faute de frappe oblige à retaper un bloc entier, la fenêtre finit par se fermer, et tout disparaît avec elle. Le repère à garder est simple : dès qu'un morceau de code mérite d'être relancé une deuxième fois, il mérite d'être dans un fichier.
Une variable définie dix minutes plus tôt existe encore dans la session. Un extrait qui fonctionne parfaitement dans le REPL peut donc échouer avec une NameError au premier lancement du script correspondant, simplement parce que rien n'y définit cette variable avant de s'en servir.
Le pont entre les deux mondes tient dans une seule option. python -i exécute d'abord le fichier normalement, puis vous laisse dans le REPL avec toutes ses variables déjà chargées : c'est la façon la plus directe d'inspecter l'état d'un programme juste après son point d'entrée, sans rien retaper à la main.
python -i mon_script.pyQuestions fréquentes
Comment sortir du REPL ?
Avec exit(), ou avec le raccourci du terminal : Ctrl+D sous macOS et Linux, Ctrl+Z suivi d'Entrée sous Windows. Les versions récentes acceptent aussi exit sans parenthèses, ce qui a longtemps produit un message de rappel plutôt qu'une sortie.
Pourquoi mon bloc indenté ne s'exécute-t-il pas ?
Parce que le REPL attend encore la fin du bloc. Après une définition de fonction, l'invite passe à trois points et l'indentation se poursuit jusqu'à ce qu'une ligne vide vienne refermer l'ensemble. Un code collé qui contient déjà une ligne vide au milieu se retrouve donc coupé en deux.
Faut-il installer IPython plutôt que d'utiliser le REPL de base ?
IPython apporte la complétion, la coloration et des raccourcis de mesure du temps d'exécution, mais il faut d'abord l'installer, ce que le REPL standard n'exige jamais. Celui-ci est déjà présent sur toute machine où Python tourne, y compris un serveur distant où vous préférez ne rien ajouter. Commencez par le REPL standard, et passez à IPython le jour où cette absence de confort commence vraiment à se faire sentir.