Skip to content
  • Home
  • How To
  • M0
  • Module 1 - Python
  • Agents
  • M2
  • M3
  • M4
  • M5
  • M6
  • Progress
  • Contact
  • Pricing
  • Sign in
  • Future
  1. Module 1M1
  2. ›
    S1Python Foundations
  3. ›
    Lesson 1 of 4Running Python - The Interpreter, the REPL, and Your First Script
  4. ›
    S1›Lesson 1 of 4
  1. Module 1
  2. ›
  3. Section 1
  4. ›
  5. Lesson 1

Running Python - The Interpreter, the REPL, and Your First Script

FREE·~1.5 h·2 labs·4 questions·1 assignment


Context

Python is a program that reads text you wrote and carries out the instructions in it. It can do that two main ways, one line at a time at an interactive prompt that answers immediately, or all at once from a saved file handed to it from the terminal.

Both modes stay with you for the rest of your work. The prompt is where you check what a column of values actually contains, or what a number rounds to, before committing that guess to anything larger. The file is where every real piece of work lives, because a training run, a cleaning pass, or a report has to be repeatable by you tomorrow and by someone else next month, and only a saved file can be run twice and get the same answer.

Confuse the two and results evaporate. Work typed at the prompt vanishes when the window closes, and a file that computes the right answer but never says so prints nothing at all, which is easy to mistake for a crash. Module 0 left you able to start a program from the shell and read the exit status it returned, so you already know how to launch a process, this lesson makes that process yours.


Goal

  • Launch the Python REPL from your terminal and evaluate single expressions interactively.
  • Write a .py file in VS Code and run it as a process from the terminal with python3.
  • Distinguish a value (a piece of data) from an expression (code that produces a value) from a statement (an instruction that performs an action).
  • Send a value to the terminal on demand using print, and explain why a script needs it while the REPL does not.
  • Read a script's exit status to tell a clean finish apart from a crash.

Prerequisites

Neither of these is required and the lesson assumes you skipped both. They are here only if you would rather see the shape of the thing before you build it, and Theory starts from zero either way.

  • YouTube - "Python Full Course for Beginners" by Programming with Mosh. The first ~15 minutes, covering the interactive shell and running a file. Watch for the mental picture, not to memorize.
  • Official docs - The Python Tutorial, "Invoking the Interpreter". The first three paragraphs, showing how the interpreter is started.

Table of Contents

  • Python Interpreter
  • REPL (Interactive Mode)
  • Value
  • Expression
  • Statement
  • print / Console Output
  • Script Execution

Theory

Python Interpreter

What. The Python interpreter is the program, an executable named python3 on your system, that reads Python source text and executes its statements one at a time, from the top. Why. Python is not compiled ahead of time into a standalone machine binary the way C is, instead, a single program reads your .py text (or what you type live) and carries out the instructions immediately. When. Every single time you run Python, interactively or from a file, you are starting this one program. There is no Python without the interpreter.

When you run python3 something.py, the operating system launches the interpreter as a process, the same kind of running program you watched start and exit in Module 0. That process loads your file, executes it, and then ends. Understanding that "running Python" literally means "launching the interpreter process" is the mental model that the rest of this lesson builds on.

There is nothing magical about the interpreter: it is one more executable on disk, like ls or git. You give it work (typed lines or a file), it does the work, it exits.

DON'T:

  • DON'T assume python and python3 are always the same program, on some machines python is missing or points to an old Python 2. Prefer python3.
  • DON'T think of Python as "compiling to an .exe." The interpreter turns your source into bytecode and runs it in the same process, there is no separate build step here.

REPL (Interactive Mode)

What. The REPL is Python's interactive prompt: you type one expression, press Enter, and it instantly shows the result. The name is the loop it runs, Read your input, Evaluate it, Print the result, Loop back for more. Why. It is the fastest possible feedback loop: no file to save, no command to re-type, just an immediate answer. It is where you test a small idea before committing it to a script. When. Use it for quick experiments, "what does this expression evaluate to?", "does this syntax work?", never for code you want to keep.

Start it by running the interpreter with no file argument.

# Running 'python3' with no filename starts the interactive prompt instead of a script.
python3

You now see the prompt >>>. That triple-arrow is Python waiting for you to type.

# Type this at the '>>>' prompt and press Enter, this is an arithmetic expression.
2 + 2

The REPL prints 4 on the next line. You did not ask it to print anything, interactive mode auto-displays the value of the expression you type. That auto-display is unique to the REPL and is the single biggest difference from running a script.

# 'learning_rate' is given the value 0.01, this line stores, it does not display.
learning_rate = 0.01
# Typing the name alone is an expression, so the REPL echoes its current value.
learning_rate

That silent-then-loud pair is the value / expression / statement split arriving early, and the next three subtitles name it properly.

Leave the REPL with the exit() call or by pressing Ctrl-D.

# 'exit()' tells the interpreter to stop interactive mode and return you to the shell.
exit()

You are back at your normal terminal prompt. The interpreter process has ended.

DON'T:

  • DON'T write multi-step programs in the REPL, every name you bound vanishes the moment you exit, and nothing you typed becomes a file you can run.
  • DON'T confuse the REPL's automatic echo with print. The auto-display only happens in interactive mode, a script never echoes a value on its own.

Value

What. A value is a concrete piece of data your program works with, the number 42, the text "accuracy", the truth-value True. Why. Values are the raw material of every program, everything Python does is ultimately about producing, combining, and moving values around. When. Every time you write a literal, a number, a quoted string, a True/False, you have written a value directly into your code.

A value written directly in source is called a literal. Each of the lines below is a single literal value.

# An integer literal: a whole number value, here standing in for a batch size.
64
# A floating-point literal: a number with a decimal point, here a learning rate.
0.01
# A string literal: text wrapped in quotes, here the name of a metric.
"accuracy"
# A boolean literal: one of exactly two truth-values, 'True' or 'False'.
True

Typed alone into the REPL, each of those is echoed straight back, a string in single quotes as 'accuracy', because a literal already is its own value and there is nothing left to compute. 64 evaluates to 64. That makes a literal the simplest possible expression, a value standing for itself.

Values have types, which the next lesson covers in depth. For now the idea is smaller: a value is data sitting in your program waiting to be used, and when you eventually load a dataset of thousands of numbers, every one of them is a value, just as the 64 you typed is one.

DON'T:

  • DON'T wrap numbers in quotes when you mean a number, "64" is a string value (text), not the number 64. They behave differently.
  • DON'T confuse a value with a variable name. 64 is a value, batch_size is a name that might refer to it.

Expression

What. An expression is any piece of code that Python can evaluate down to a single value. Why. Expressions are how you compute new values from existing ones, every calculation, comparison, and lookup your programs ever do is an expression being evaluated. When. Whenever you combine values and operators, call something that returns a result, or even just write a literal, you have an expression.

The defining test: does this code produce a value? If yes, it is an expression.

# Two integer literals combined by the '+' operator, the whole line evaluates to 5.
2 + 3
# A literal combined with a name, if 'learning_rate' is 0.01 this evaluates to 0.02.
learning_rate * 2
# A comparison expression, it evaluates to the boolean value 'True' or 'False'.
64 > 32

The operators (+, *, >) each combine smaller values into a single new one, and that reduction-to-a-value is exactly what makes something an expression.

Expressions nest. In 2 + 3 * 4 the inner expression 3 * 4 evaluates to 12 first, then 2 + 12 evaluates to 14. Operator precedence (how a mixed expression is grouped) is the subject of a later lesson, for now hold only the idea that an expression is a value-producing recipe, however large. Because an expression always becomes a value, you can put one anywhere a value is expected, bind it to a name, print it, or feed it into a bigger expression.

DON'T:

  • DON'T expect an expression to do anything visible on its own inside a script, computing 2 + 3 in a file produces the value 5 but shows nothing unless you print it.
  • DON'T call an assignment like x = 5 an expression, it performs an action and yields no usable value. That is a statement, covered next.

Statement

What. A statement is a complete instruction that performs an action rather than producing a value. Why. Programs need to do things, store data, repeat work, make decisions, and statements are the unit of "doing." When. Assigning a name, printing a value, pulling in ready-made code, or defining a reusable block of steps all happen via statements, they are the steps a script executes top to bottom.

The clearest first example is assignment: it binds a name to a value.

# 'epochs' is the name on the left, '=' binds it to the value 10 on the right.
epochs = 10
# This statement REBINDS the same name to a new value, the old 10 is forgotten.
epochs = 20

Neither line evaluates to a usable value, and that is the signature of a statement. Contrast it with an expression: epochs + 5 produces 25, while epochs = 25 performs the action of binding and produces nothing. The rule of thumb is an expression has a value, a statement has an effect. A few lines blur the two, but the distinction stays useful all the way through the course.

In a script, statements run in order, top to bottom. That ordered sequence of actions, bind this, compute that, print the other, is what a program is.

DON'T:

  • DON'T try to use an assignment where a value is needed, e.g. total = (epochs = 5) is an error, assignment is a statement, not a value you can pass along.
  • DON'T assume rebinding a name changes the old value, epochs = 20 does not alter the number 10, it just stops epochs from pointing at it.

print / Console Output

What. print is a built-in that takes any number of values and writes their text form to stdout, the standard output stream you send to the terminal. Why. A script does not auto-display results the way the REPL does, so without print a running file shows none of them. print is your first deliberate window into what a program is doing. When. Use it any time a script needs to show a result, report progress, or, very soon, let you debug by inspecting values mid-run.

print is a statement-like action: calling it performs the effect of writing to the stream. It is a deliberate write to the same stdout you learned to redirect in Module 0.

# 'print(...)' sends the value inside the parentheses to 'stdout' (your terminal).
print(0.01)
# You can print a string literal directly, the quotes are not part of the output.
print("training complete")
# 'print' accepts several values separated by commas, it joins them with spaces.
print("accuracy:", 0.97)

The second call writes training complete with no quotes around it, because the quotes that open and close a string are Python syntax, never characters in the value itself. All three land on stdout, the exact stream you already know how to redirect into a file with >.

The contrast with the REPL is the whole point. In interactive mode, typing 0.01 echoes 0.01 for free. In a script, typing 0.01 alone shows nothing, the value is computed and immediately discarded. Only print(0.01) makes it appear. Forgetting this is the single most common "why is my script silent?" mistake of week one.

DON'T:

  • DON'T rely on the REPL's auto-echo when writing a script, a .py file never echoes a value, so print the ones you want to see.
  • DON'T confuse the quotes in "training complete" with output, they delimit the string in your code and never appear on screen.

Script Execution

What. Script execution is running a saved .py file by handing it to the interpreter from the terminal: python3 myfile.py. Why. Real programs are saved, re-runnable, and shareable, a script is a permanent, ordered list of statements, unlike the throwaway REPL. When. Use a script for anything you want to keep, repeat, or hand to someone else. Every model you eventually train is just a long, careful script like this one, launched the same way, from the same terminal.

First, write the file in VS Code. Inside ~/dev/bootcamp, where the Module 1 setup page keeps every script, create a file named first_run.py with these lines.

# A statement that binds the name 'dataset_size' to the integer value 1000.
dataset_size = 1000
# An expression ('dataset_size // 4') is computed, then bound to 'batch_count'.
batch_count = dataset_size // 4
# 'print' writes the result to 'stdout' so we can actually see it when the script runs.
print("batches per epoch:", batch_count)

The // on line 4 is integer division, so 1000 // 4 is 250. Line 4 produces that value but shows nothing on its own, only line 6's print makes it appear, which is the script-versus-REPL difference made concrete.

Now run it. In the terminal, cd into the folder that contains the file, then launch the interpreter on it.

# Hand the file 'first_run.py' to the 'python3' interpreter to run it as a process.
python3 first_run.py

The interpreter starts as a process, executes the three statements top to bottom, prints batches per epoch: 250, and exits. When it exits cleanly it returns exit code 0, the same exit status you read in Module 0. If the script had crashed, it would exit non-zero. Check it right after running:

# '$?' holds the exit code of the last command: 0 means clean, non-zero means it errored.
echo $?

That zero is the operating system's confirmation that the interpreter process ended normally, with no error left unhandled, a clean finish rather than a crash, read through the exit status you already know.

DON'T:

  • DON'T run a script from the wrong directory, python3 first_run.py only works if your terminal is in the folder that holds the file.
  • DON'T expect intermediate computations to appear, a script shows none of them except where you print, no matter how much it calculates.

Additional

The interpreter executes a script's statements top to bottom, then stops. There is no automatic looping back, so the "L" in REPL is precisely what a one-shot script lacks.


Lab Exercises

Both problems first, then both solutions. Do not peek.

Lab Exercise 1: REPL Arithmetic and Names

Covers the first half (Python Interpreter, REPL, Value, Expression).

First confirm the interpreter is reachable by asking it for its version from your terminal. Then start the REPL and, without writing a single print, type expressions that make the interpreter echo the following in order: the number 42, the result of 144 divided by 12, and the boolean result of comparing whether 256 is greater than 128. Next, bind the name learning_rate to 0.05, and on the line after that make the REPL display its value. Leave the REPL cleanly. Write down which of your lines produced output and which did not, and say what the silent ones have in common.

Lab Exercise 2: A Script, Its Silence, and Its Status

Covers the second half (Statement, print / Console Output, Script Execution).

In VS Code, inside your project folder, create metrics.py containing exactly these five lines in this order: bind correct to 90, bind total to 100, bind accuracy to the result of correct / total, print the text "accuracy:" followed by accuracy, and finally a bare line that computes correct / total again without printing or storing it.

Before running, write a comment above each of the five lines labeling it expression or statement, and predict exactly how many lines of output the script will produce. Then run the file with python3 from the terminal, confirm you see accuracy: 0.9 and nothing else, and read the exit code immediately afterwards. In a final comment, explain why the last line is silent even though it computed a real number, and why the exit code says the run was fine anyway.


Solution 1: REPL Arithmetic and Names
# '--version' asks the interpreter to print its version and exit, confirming it is reachable.
python3 --version
# Running 'python3' with no filename starts interactive mode instead of a script.
python3
# A bare integer literal, the REPL echoes it because a literal is an expression -> 42.
42
# A division expression, '144 / 12' evaluates to the float 12.0 and is echoed.
144 / 12
# A comparison expression, '256 > 128' evaluates to the boolean 'True' and is echoed.
256 > 128
# An ASSIGNMENT statement, it binds the name but produces NO echoed value.
learning_rate = 0.05
# The name alone is an expression, so the REPL echoes its current value -> 0.05.
learning_rate
# 'exit()' ends interactive mode and returns you to the shell.
exit()

Four of your lines echoed, 42, 12.0, True and 0.05, and two stayed silent. learning_rate = 0.05 performs a bind and exit() ends the session, effects rather than values, and the REPL only ever auto-displays the value an expression evaluates to.

DON'T:

  • DON'T add print() here, the REPL already echoes expressions, so print(42) would just be redundant noise.
  • DON'T expect learning_rate = 0.05 to show 0.05, assignment is an action, not a displayed value.
  • DON'T read 144 / 12 echoing 12.0 rather than 12 as a mistake, / always produces a float, which Lesson 1.1.4 takes apart.
Solution 2: A Script, Its Silence, and Its Status
# STATEMENT: binds 'correct' to 90 (number of correct predictions), silent.
correct = 90
# STATEMENT: binds 'total' to 100 (total predictions made), silent.
total = 100
# STATEMENT: the EXPRESSION 'correct / total' is evaluated, then bound to 'accuracy'.
accuracy = correct / total
# STATEMENT: 'print' writes the label and the value to stdout, joined by one space.
print("accuracy:", accuracy)
# EXPRESSION: recomputes 0.9, but nothing prints or stores it, so it is discarded.
correct / total
# Exactly ONE line of output, because only the 'print' writes to stdout. The last
# line really did compute 0.9, it just had nowhere to go, and discarding a value
# is not an error, so the process still finishes cleanly.

Run it and read the status:

# Hand 'metrics.py' to the interpreter to execute it as a process.
python3 metrics.py
# '$?' holds the exit code of the previous command, 0 means a clean finish.
echo $?

The terminal shows accuracy: 0.9, then 0. Those two facts together are the point of the exercise. A script writes to stdout only where you tell it to, so four of the five lines are invisible, and the invisibility is normal rather than a failure, which is exactly what the 0 confirms. An empty stdout and a crash look alike until you read the exit code, and only one of them is a problem.

DON'T:

  • DON'T expect the trailing correct / total to print, scripts never auto-echo the way the REPL does.
  • DON'T read a silent line as a line that did not run, it ran and its value was dropped.
  • DON'T treat echo $? as printing anything your script produced, it reports the process's status and nothing else.

Theory Assessment

Conceptual reinforcement, not a coding section. All four questions with their hints first, then all four answers.

Q1: Two Faces of One Program

Two parts, both about the interpreter itself. First, explain what the Python interpreter actually does when you run python3 first_run.py, and why that differs from how a compiled C program runs. Second, at the >>> prompt you type epochs = 10 and see nothing, then type epochs and see 10, explain why the first line is silent and the second is not.

Hint: For the first part, the question is when your source text is read and executed, ahead of time into a machine file, or on the spot by a program that is itself running. For the second, one of those two lines has a value and the other has an effect.

Q2: Label All Four

For each of these, label it value, expression or statement, and justify the label in a few words: 64 * 2, batch_size = 64, "loss", print("loss").

Hint: Apply the single test, does the code reduce to a usable value, or does it perform an action? One of the four is a value AND an expression at the same time, and saying why is the interesting part of the answer.

Q3: Follow stdout, Then Read the Status

Trace what reaches stdout, in order, when this script runs:

x = 5
x + 1
print(x)
print("done")

Then state what echo $? would print immediately afterwards, and what that number reports.

Hint: Only lines that explicitly write to stdout appear, bare expressions are discarded in a script. The exit code is a separate channel from anything print wrote.

Q4: The Script That Looks Broken

A student checks 90 / 100 at the >>> prompt, sees 0.9, and copies that exact line into check.py as its only line. Running python3 check.py prints nothing at all, so they conclude the script failed to run. They then check echo $? and see 0, which confuses them further.

Explain what actually happened, why the blank terminal is not evidence of failure, and why a 0 and an empty screen are perfectly consistent with each other. Then give the one-word fix.

Hint: Three separate things are in play, the REPL's auto-echo, what a script sends to stdout, and what an exit code measures. Ask what each of the three would have to be for the student's "it failed to run" reading to be true.


Answer 1:

The interpreter is a program that reads your .py source text and executes its statements at run time, one after another from the top, as a process, and no separate machine-code file is produced first. A compiled C program is translated ahead of time into a standalone binary, and that binary is what the OS runs. With Python the python3 interpreter is always the thing running, consuming your source on the spot.

The two REPL lines split the same way values and effects always do. epochs = 10 is a statement: it performs the action of binding the name epochs to 10 and yields no displayable value, so nothing appears. epochs on its own is an expression that evaluates to the value 10, and interactive mode automatically prints the value of any expression you enter except None, the explicit nothing the next lesson introduces, so 10 appears.

DON'T say Python "compiles to an .exe", that conflates it with the compiled-binary model and misses that the interpreter runs your source itself, with no binary produced first. And DON'T describe the REPL as "remembering and showing the assignment", it only ever echoes expression values, never the effects of statements.

Answer 2:
# 'expression': two values and the '*' operator reduce to one value, 128.
64 * 2
# 'statement': '=' performs a bind action and yields no usable value.
batch_size = 64
# 'value', and therefore also an 'expression': a literal evaluates to itself.
"loss"
# action/statement-like: 'print(...)' performs the effect of writing to stdout.
print("loss")

64 * 2 is an expression, it reduces to 128. batch_size = 64 is a statement, it performs a bind and has no value. print("loss") performs the action of writing to stdout, so it is used as a statement rather than for a value it hands back.

"loss" is the interesting one, because both labels fit. It is a value, a string literal written directly into the source, and it is simultaneously the smallest possible expression, since evaluating it produces that same value. Every value written as a literal is an expression that stands for itself, which is why the REPL echoes a bare "loss" straight back, displayed as 'loss'.

DON'T call print("loss") "just an expression", its purpose is the side effect of output, not producing a value to use.

Answer 3:
# Statement: binds 'x' to 5, writes nothing to stdout.
x = 5
# Expression: evaluates to 6 but is not printed, so it is discarded -> no output.
x + 1
# Action: prints the value of 'x' -> 5
print(x)
# Action: prints the string -> done
print("done")

stdout receives, in order, 5 and then done. The assignment is silent, and the bare expression x + 1 really does evaluate to 6, but it is never printed so the value is dropped.

echo $? then prints 0. That is the interpreter process's exit code reported to the operating system, and 0 means it ended normally, with no error left unhandled. It says nothing whatever about how many lines were printed.

DON'T include 6 in the output, a bare expression in a script produces no visible result.

Answer 4:

Nothing failed. The REPL echoed 0.9 because interactive mode auto-displays the value of an expression you type, and that echo is a feature of the REPL rather than of the line. Copied into a script, the same expression 90 / 100 is evaluated to 0.9 and then immediately discarded, because a script writes to stdout only where you explicitly send something there. The computation ran, its result had nowhere to go.

The blank terminal is not evidence of failure because an empty stdout and a crash are two different things that happen to look alike, and the exit code is the channel that tells them apart. 0 means the process ended normally, with no error left unhandled. The two observations are consistent precisely because they measure different things: stdout reports what the program chose to say, the exit code reports whether the process finished cleanly. A crashed run would have printed a traceback to stderr and reported a non-zero status, so the student saw neither of the two signals a real failure produces.

The one-word fix is print, as print(90 / 100).

DON'T conclude "the math didn't run", and DON'T treat silence as a diagnosis at all. Read the exit code before deciding anything, because it reports how the run ended even when nothing reached the screen.


Assignment

One assignment. The problem and its hints first, then the solution.

Assignment: One Program, Three Launches, One Status

Write launch.py that binds dataset to "mnist", binds rows to 60000, and prints "dataset:" then dataset then "rows:" then rows on a single line. Then, from the terminal: (1) run it the normal saved-file way, (2) run the same three statements inline using the interpreter's -c flag with no file involved at all, and (3) after each of those two runs, read and report the exit code. Finally, deliberately break launch.py with a typo (for example prnt(...)), run it again, read the exit code, and explain in a comment how the exit code changed and what that change tells you that the printed output alone could not.

Hints:

  • The -c flag runs a quoted program directly, so separate its statements with semicolons since they all share one line. Wrap the whole program in double quotes and use single quotes for any string inside it, so the shell does not split the command apart.
  • A clean run reports exit code 0 and a run stopped by an error it did not handle reports a non-zero one, which is exactly how you tell a finished run from a crashed one when the output on screen is ambiguous.

Solution:

launch.py:

# Bind 'dataset' to the string "mnist" (the name of our dataset).
dataset = "mnist"
# Bind 'rows' to 60000 (number of samples in the dataset).
rows = 60000
# Print all four pieces on one line, 'print' joins them with single spaces.
print("dataset:", dataset, "rows:", rows)

Launch one, the saved file, then read status:

# Normal execution of the saved file as a process.
python3 launch.py
# Read the exit code of that run, 0 means a clean finish.
echo $?

Launch two, the same statements inline with no file, then read status:

# '-c' runs the quoted program directly, ';' separates the statements on one line.
python3 -c "dataset = 'mnist'; rows = 60000; print('dataset:', dataset, 'rows:', rows)"
# Read the exit code of the inline run, again 0 for a clean finish.
echo $?

Launch three, with the typo introduced, then read status:

# A deliberate typo: 'prnt' is not a real built-in, so this line raises a NameError.
prnt("dataset:", dataset, "rows:", rows)
# Run the broken file, the interpreter raises an error and stops.
python3 launch.py
# Read the exit code, a crash reports a NON-ZERO value (here 1).
echo $?
# The exit code went from 0 (clean) to 1 (error). A non-zero status is the OS's
# report that the interpreter process ended because of an error rather than
# normally, which is what tells a finished run apart from a crashed one.

Both clean runs print dataset: mnist rows: 60000 and both report 0. The -c form hands the same three statements to the same interpreter from a command-line string instead of a file, and the interpreter does not care which, so the output is identical.

The broken run is where the assignment earns its place. The interpreter raises a NameError (a name that is not defined, because no built-in is spelled prnt), stops, and exits non-zero, so echo $? prints 1. What the printed output alone could not tell you is the whole point: the traceback went to stderr rather than stdout, so a pipeline capturing only stdout would have seen the same emptiness a silent-but-successful script produces. The status is the channel that separates them, which is why you read it rather than trusting the screen.

DON'T ignore the non-zero exit code or read partial output as success, once an error goes unhandled the run did not finish, and the status is the only place that fact is stated unambiguously.


Additional Resources

Optional, and nothing later in the bootcamp depends on either one. Worth opening only if this lesson left you curious.

  • YouTube - "Python Tutorial for Beginners" by freeCodeCamp.org. The "Python Interpreter" and "Text Editor" chapters, for a second visual pass on the interactive prompt, opened from a terminal and then from the one built into VS Code.
  • Official docs - Python Setup and Usage, "Command line". How the interpreter receives the script name and the arguments after it, which extends script execution past what this lesson needed.

Summary

This lesson was about the simplest, most physical fact of programming in Python: there is one program, the interpreter, and everything you ever do is a way of handing it work. You met it twice, wearing two faces. As the REPL it is a patient conversational partner: type one expression, get one answer, forget it, repeat. As a script runner it is a quiet machine: hand it a file, watch the process run top to bottom and exit. The same python3 underneath both, the same statements, the same values flowing through, only the source of the work and the permanence of it change.

Underneath the two ways to run sat a distinction that will quietly organize the rest of your Python life: values are the data, expressions are the code that produces values, and statements are the code that does things. The REPL made that split visible for free by echoing expressions and staying silent on statements. The script took the training wheels off, compute all you like, but nothing reaches your eyes until you deliberately print it to stdout, the very stream you learned to follow in Module 0. The exit code closed the loop, letting the operating system tell you whether the process you launched finished its work or fell over.

None of this looks like machine learning yet, and that is the point. The grand training runs ahead of you are not a different kind of thing, they are long, careful scripts launched from this same terminal, printing to this same stream, exiting with this same status. You have just learned how to start them and how to read whether they worked. Everything that follows is filling in what goes between the first line and the last.


Cheat Sheet

Part A - Reference Table

Concept What it is How you do it / spot it When to avoid
Interpreter Program that runs Python source python3 --version confirms it Never, every run needs it
REPL Interactive one-line-at-a-time prompt python3 (no file) → >>> Anything you want to keep
Script execution Running a saved .py file python3 file.py Quick one-off checks
Value A concrete piece of data 42, 0.01, "acc", True Never, all data is values
Expression Code that produces a value 2 + 3, x * 2, 64 > 32 When you need an action, not a value
Statement Instruction that performs an action x = 5, print(x) When you need a usable value back
print Writes a value to stdout print("acc:", 0.97) Relying on it in the auto-echoing REPL
Exit code Process's clean/error report echo $? → 0 is clean Ignoring a non-zero result

Part B - Compact Code Block

batch_size = 64             # statement: binds a name (silent)
batch_size * 2              # expression: makes a value (discarded in a script)
print("size:", batch_size)  # action: writes value to stdout
# REPL auto-echoes expressions, a script never does
←Previous: Module 1
Next: Lesson 2→

Questions about this lesson: #module-1 on Discord

Found an error in this lesson? Report it

Your progress
Current streak
🔥 0
Lessons marked today
0 / 3
Longest streak
0

Sign in

The bootcamp

  • Curriculum
  • How To
  • Pricing
  • Changelog
  • Future

The community

  • Discord
  • Reviews
  • Contact

Follow

  • Instagram
  • X
  • TikTok
  • Reddit

Legal

  • Terms
  • Privacy
  • Refunds

Coming soon on November 16, 2026

Theme