Meet the Python Interpreter

Core path: 30 minutes

How does source code become a running program?

Lesson 1 ended with a file full of instructions. That file can be perfectly written and still do nothing until something executes it.

This lesson is about that missing layer.

hello.py is text on disk

Create a file named:

hello.py

and put this inside it:

print("Python is running.")

At this moment, nothing has been printed.

The file exists. The instruction exists. The program is not running.

That distinction matters. The editor can display source code all day without executing it. Saving a file changes what is stored on disk; saving does not automatically mean "run this program now."

The .py extension is the normal convention for Python source files. It helps humans, editors, operating systems, and development tools recognize the file as Python. The text itself is still text. In fact, the Python interpreter can technically be given a differently named text file if that file contains valid Python source. The extension is important tooling context, not magic dust sprinkled onto the file.

The interpreter is another program

To run hello.py, we launch the Python interpreter and give it the path to our source file:

python hello.py

Depending on the system, the command may be python3 instead of python. The name is less important than the relationship:

Read that flow from left to right:

• the source file contains Python instructions;
• the terminal is where we issue the command;
• the python command launches the interpreter;
• the interpreter processes the source and executes the program;
• the program produces output.

If the program prints text, you might see:

Python is running.

The terminal did not invent that sentence. It displayed output produced by the program that Python executed.

Coding punctuation cheat sheet

Programming uses characters you have seen before, but developers often use specific names for them. Knowing the names matters because directions and error messages may say things like "add a closing parenthesis" or "put the value inside square brackets."

You do not need to memorize this whole list today. Keep coming back to it.

• ( and ) are parentheses. One is an opening parenthesis and the other is a closing parenthesis. Function calls such as print("Hello") use them.
• [ and ] are square brackets or simply brackets. Later you will use them for lists, indexes, and slices.
• { and } are curly braces or curly brackets. Later you will see them around dictionaries and sets.
• : is a colon. Python uses it before indented blocks such as if, for, while, functions, and classes. It also appears in slices and dictionaries.
• ; is a semicolon. Python allows it in a few places, but this course almost never needs it. One statement per line is easier to read.
• , is a comma. It separates items or arguments: print("Nova", 100).
• . is a period or dot. You will use dot notation later, such as player.score and text.lower().
• " is a double quotation mark or double quote. ' is a single quotation mark or single quote. Python can use either style to mark string text.
• # is called a hash, number sign, or sometimes pound sign. In Python it starts a comment.
• _ is an underscore. Python variable names commonly use it: player_score.
• = is the equals sign, but in Python = is the assignment operator. score = 10 assigns the value 10 to the name score.
• == is double equals or the equality operator. It asks whether two values are equal. It is not the same operation as =.
• != is read not equal. Some developers informally call ! bang, so you may hear "bang equals."
• < and > are less-than and greater-than signs. <= and >= include equality.
• +, -, *, and / are plus, minus, asterisk (often read as "times" in arithmetic), and forward slash.
• // is double slash and performs floor division in Python.
• % is the percent sign or modulo operator when used for remainder arithmetic.
• ** is double asterisk and means exponentiation in Python.
• \ is a backslash. / is a forward slash. Do not treat them as interchangeable in every context.
• | is a vertical bar or pipe. You will see it frequently in terminal commands and later in some Python type syntax.
• & is an ampersand. It appears in several programming and shell contexts.
• @ is the at sign. Advanced Python uses it for decorators; you do not need decorators yet.

The point is not vocabulary trivia. The point is communication. If I say "you are missing the closing square bracket," you should know exactly which character I mean.

Comments: notes for the humans reading the code

Python ignores a comment that begins with # and continues to the end of that line:

# This comment explains why the program prints this message.
print("Python is running.")

Comments are part of source code, but they are mainly for humans, not the program's output.

Good comments explain something useful that the code does not make obvious:

# Keep the threshold at 20 because the device must stop before the battery reaches 0.
low_battery = 20

A weak comment merely repeats the code:

# Set score equal to 10
score = 10

Later, the full weekly Python examples will use comments to point out structures such as loops, conditions, function boundaries, file operations, and tests. Read those comments as part of the lesson, then try removing the comments and explaining the code yourself.

What Python actually does first

There is one beginner simplification worth cleaning up early.

People sometimes say, "Python just reads one line and immediately runs it." That is useful as a rough mental model for top-level execution order, but it is not the whole story.

Before normal execution begins, Python has to make sense of the source code's structure. If the syntax is invalid, Python can reject the file before reaching the behavior you expected.

Once the source is structurally valid, top-level statements generally execute in order unless your code introduces control flow that changes what happens next.

For this file:

print("ONE")
print("TWO")
print("THREE")

predict the output before running it.

You should expect:

ONE
TWO
THREE

Now reverse the first and last source lines. The output order changes because the instruction order changed.

Run the same idea directly in the browser and use the output as evidence:

Run the code to see output.

This sounds obvious in a three-line program. It becomes much less obvious when functions, loops, conditions, files, and multiple modules enter the picture later. Start building the habit now: when behavior surprises you, trace what actually executed.

Break the source on purpose

Change:

print("Python is running.")

to:

print("Python is running."

Run the file again.

Do not fix it immediately.

Read what Python reports.

Because the source structure is incomplete, Python should report a syntax problem and point you toward the location where parsing failed. The exact wording can vary by Python version, but the important evidence is still there: the file, a location, and an error description.

Use the intentionally broken browser example once before repairing it:

Run the code to see output.

This is different from a program that starts executing and then crashes later. We will learn those differences properly in Week 7. For now, you only need one habit:

Read the error before changing the code.

Random edits destroy evidence.

A typo can survive syntax and fail later

Now repair the parenthesis and introduce a different mistake:

pritn("Python is running.")

The structure is valid Python. The name pritn is the problem.

Run it.

This time Python gets farther. It can parse the statement, but when execution reaches the unknown name, the program fails.

Compare that failure directly with the syntax example:

Run the code to see output.

Compare the two failures:

• missing ) → Python cannot correctly parse the source structure;
• pritn(...) → Python can parse the statement, but execution cannot resolve that name.

You do not need the formal error taxonomy yet. Just notice that different mistakes leave different evidence.

That becomes extremely useful later.

Trace one run from command to evidence

Suppose the file contains:

print("BOOT")
print("READY")

You type:

python hello.py

Here is what you should be able to explain without hand-waving:

1. The shell receives the command.
2. The command launches the Python interpreter and gives it hello.py.
3. Python processes the source file.
4. The first print() executes and produces BOOT.
5. The second print() executes and produces READY.
6. The program reaches the end of the file and exits.

Output:

BOOT
READY

Run the exact two-statement program here, then reverse the lines and explain the changed evidence:

Run the code to see output.

That is a complete cause-and-effect chain. No magic. No "the computer just knows."

One more distinction: language, interpreter, program

These words are easy to collapse into one blob when everything is new.

Python the language is the syntax and rules used to express the instructions.

The Python interpreter is software that processes and executes Python programs.

Your program is the source code and behavior you created for a specific task.

They work together. They are not the same thing.

If that feels overly picky, good. Technical systems become much easier to debug once you stop treating every layer as "the computer."