Definition
You just want to check one thing: what a method hands back, the value of an expression, the exact spelling of a keyword. Opening a file for that, saving it, then running it, takes far longer than the question itself. That is exactly the problem the REPL solves.
The REPL is the interactive Python prompt. You type one line, it runs straight away, and the result is displayed without asking for anything more. The four letters name the loop turning behind it: read what you typed, evaluate it, print the result, then loop again. It opens by starting the interpreter without handing it a file to run, and you recognise it at a glance by its three-chevron prompt.
pythonOnce inside, two quick tries show exactly what that looks like.
>>> 3 * 7
21
>>> "a,b,c".split(",")
['a', 'b', 'c']No call to print was needed anywhere, and yet each result appears: the REPL prints it itself, not your code. It does not display it the way a print would either, since it passes the value through repr, the representation meant for a developer rather than an end reader. That is why the string shows up here surrounded by its quotes: a print would have shown it bare.
What it saves you
You want to know exactly what split hands back on a string ending with a comma. Without the REPL you have to open a file, write a print, save it, run the script, read the output, then start the whole thing over for the next question. The REPL brings that entire cycle down to one typed line and one Enter key.
What it replaces in practice is the test.py file almost everyone ends up creating at the root of the project, filled with drafts and never cleaned up. What it does not replace is the file itself. A one-off check has no reason to outlive the question it settled; a piece of logic you will want to revisit tomorrow does.
The table below sets the two side by side, for the situations where one clearly beats the other.
| What you are doing | In the REPL | In a file |
|---|---|---|
| Replaying the same code tomorrow | It vanished when the window closed | One command is enough |
| Fixing one line of a block | The whole block must be retyped | You edit, you rerun |
| Showing that code to someone | A copy-paste of the session | A file under version control |
| Trying an idea in ten seconds | This is exactly its ground | Three steps too many |
The three uses worth the detour
The first is checking a behaviour you are not certain about. Does this method hand back a new value, or change the object in place? A search through the documentation answers that in theory, three seconds of trying answer it in practice.
The second is inspection. type(obj) gives its nature, dir(obj) the list of what it can do, and help(obj) shows its documentation without leaving the terminal. Faced with an unfamiliar library, these three commands often replace reading the whole manual.
The third is checking an installation. After a pip install, one import line in the REPL says immediately whether the library landed in the interpreter that is actually answering, which is not always the one you think you are using. A ModuleNotFoundError at that exact moment nearly always points to a forgotten virtual environment, rather than a genuine installation problem.
One more advantage, quieter but real: an error raised here prints a two-line traceback instead of twenty. Cut off from the rest of the program, it becomes far easier to read.
The classic mistake, and the bridge to files
The beginner mistake is writing a real program inside the REPL, because it is going well at first. After forty lines, one typo forces a whole block to be retyped, the window eventually closes, and everything disappears with it. The rule of thumb is simple: as soon as a piece of code deserves to be run a second time, it deserves to live in a file.
A variable defined ten minutes earlier still exists in the session. A snippet that works perfectly in the REPL can therefore fail with a NameError the first time the matching script runs, simply because nothing in it defines that variable before using it.
The bridge between the two worlds comes down to a single option. python -i runs the file normally first, then leaves you inside the REPL with all its variables already loaded: it is the most direct way to inspect the state of a program right after its entry point, without retyping anything by hand.
python -i my_script.pyFrequently asked questions
How do you leave the REPL?
With exit(), or with the terminal shortcut: Ctrl+D on macOS and Linux, Ctrl+Z followed by Enter on Windows. Recent versions also accept plain exit, without parentheses, which for a long time produced a reminder message instead of an actual exit.
Why does my indented block refuse to run?
Because the REPL is still waiting for the end of the block. After a function definition the prompt switches to three dots and the indentation carries on until a blank line closes the whole thing. Pasted code that already contains a blank line in the middle therefore gets cut in two.
Should IPython be installed rather than using the plain REPL?
IPython brings completion, colour and shortcuts for timing execution, but it has to be installed first, which the standard REPL never requires. The plain one already sits on every machine where Python runs, including a remote server where you would rather add nothing. Start with the standard REPL, and move to IPython the day that missing comfort really starts to be felt.