A Python Run Is an Evidence Chain

Why this matters: a run needs an identity

You type three lines into an editor, press a triangular button, and see text in a panel. Which program produced that text? Which saved file did it read? Which Python installation interpreted the file? Did the process finish successfully, or did the panel hide an error?

Those questions may sound advanced, but they explain many first-week failures. A learner edits one file and accidentally runs another. An editor uses Python 3.12 while a terminal resolves an older interpreter. Output from a previous run remains visible. A script prints two correct lines and then fails, but the visible lines are mistaken for a successful result.

The first dependable Python skill is therefore not memorising print(). It is being able to identify a run and connect its evidence to the exact source and runtime that produced it.

Learning objectives

By the end of this lesson, you will be able to:

• distinguish source text, an interpreter, a process, standard output, standard error, and exit status;
• explain why saving a file and running a file are separate events;
• trace the evidence chain for a small Python script;
• predict the order of visible output before execution;
• identify what a clean exit proves and what it does not prove; and
• reject a run record that cannot be connected to exact source and runtime identities.

Prerequisites

You need only basic file-navigation skills. You do not need prior programming experience, a particular editor, Git, a virtual environment, or permission to install packages.

Examples use CPython 3.12. The commands that identify an interpreter differ by operating system and are introduced in the next lesson. For now, concentrate on the parts of a run and the evidence they leave.

Mental model: source becomes evidence through a process

A Python run has an ordered chain:

saved source text
    -> selected Python interpreter
    -> one running process
    -> ordered evaluation
    -> standard output, standard error, and exit status

Read the model from left to right:

1. Saved source text is the content of a particular file on disk. Unsaved text visible in an editor is not yet that file's content.
2. The selected interpreter is an executable program, normally CPython in this course. A computer can contain several Python executables.
3. A process is one running instance of the interpreter. It has a starting directory, a command, and its own lifetime.
4. Ordered evaluation is the work Python performs after it has accepted the source as valid syntax.
5. Evidence includes ordinary output, error output, and a numeric exit status returned when the process ends.

The arrows do not mean that every run succeeds. They show where to investigate. If the shell cannot find an interpreter, no Python process begins. If the interpreter cannot locate the file, it cannot read the intended source. If the source cannot be parsed, its statements do not begin executing. If execution starts and later fails, earlier effects may already be visible.

Terminology and invariants

Source text and source file

Source text is Python code written as characters. A source file stores that text, conventionally with a .py suffix. The suffix helps tools and people recognize the file; it does not prove that the content is valid Python.

An editor changes an in-memory document while you type. Saving asks the editor to write that document to a file. Running asks some tool to start a process. These are distinct state changes.

Interpreter and process

An interpreter is the executable capable of parsing and executing Python. A process is one active run of that executable. Starting the same interpreter three times creates three processes, each with separate output and an independent exit status.

This distinction matters when a program appears to “remember” a previous run. A simple script does not retain its names after its process ends. Visible text may remain in the terminal, but that display is history, not live program memory.

Standard output and standard error

A process normally has two text channels:

• standard output, abbreviated stdout, carries intended ordinary output;
• standard error, abbreviated stderr, carries diagnostics and uncaught-error information.

Both may appear in the same terminal using different styling. Color is not a reliable distinction: themes vary, redirected output may have no color, and assistive technology should not need color to identify a channel. The process and capture method determine the channel.

Exit status

When a process ends, it returns an integer exit status to its parent process. By convention, zero indicates a clean exit and a non-zero value indicates failure. The precise non-zero value is not a universal diagnosis.

A zero exit status proves only that the process ended without reporting failure through that mechanism. It does not prove that:

• the intended source file ran;
• the output met its requirement;
• every relevant input was tested; or
• the program has no defects.

Correctness needs an expected result and a comparison, not merely a clean exit.

Worked example: trace the Pocket Library status run

Pocket Library is the synthetic reading tracker built across this course. Its first artifact has no interactive input and stores no personal data. It displays a fixed status card.

Create a file named pocket_status.py containing exactly:

print("Pocket Library")
print("Catalog: synthetic-demo")
print("Known titles:")
print(2 + 1)

Before thinking about a command, trace the four statements in source order.

The exact output contract is:

Pocket Library
Catalog: synthetic-demo
Known titles:
3

There are four lines, in that order. There is no blank line, no quotation mark in the output, and no space before 3.

Assume a verified CPython 3.12 command runs the saved file. Python first parses the complete source. If parsing succeeds, it executes statements from top to bottom. Each print() call writes a line to stdout. If all four calls complete and no uncaught error follows, the process exits cleanly.

The evidence is stronger than “I saw the words.” It binds:

• a source filename: pocket_status.py;
• the saved source content shown above;
• a selected CPython 3.12 interpreter;
• one run command and starting directory;
• four expected stdout lines;
• no expected stderr; and
• expected exit status zero.

The next lesson makes runtime and directory identity observable. Until then, treat those two fields as required but not yet filled.

Intentional boundary: clean execution with wrong behavior

Change the final statement to:

print(2 + 2)

The file is valid Python. The process can execute all four statements and exit with status zero. Its final line is 4, so it violates the stated output contract.

This is a crucial boundary:

clean exit != verified requirement

The interpreter checks Python's rules. It does not know that Pocket Library currently contains three synthetic titles. That fact belongs to the requirement and expected result. A verification record must compare actual evidence with that expectation.

Now imagine the editor shows print(2 + 1), but the change has not been saved. Running the file can still produce 4 because the process reads the older text on disk. Repeatedly pressing Run cannot repair the mismatch. Save state and source identity must be investigated.

Guided practice: classify one run record

Use this supplied record:

source shown in editor: pocket_status.py with final line print(2 + 1)
save state: unknown
interpreter: Python 3.12, executable path not recorded
working directory: not recorded
command: python pocket_status.py
stdout:
Pocket Library
Catalog: synthetic-demo
Known titles:
4
stderr: empty
exit status: 0

Stage 1: compare output

Compare each actual line with the contract. Lines 1–3 agree. Line 4 does not: expected 3, observed 4.

Stage 2: state only demonstrated facts

The run ended cleanly and produced a mismatching final line. The record does not prove that the visible editor content was saved, that the intended file path was used, or which executable the command name resolved.

Stage 3: list discriminating checks

A useful next check separates plausible explanations. Record the saved file content, exact resolved source path, process working directory, and interpreter executable, then rerun once. Do not immediately edit arithmetic: that could hide a stale-file or wrong-file problem.

Stage 4: decide whether evidence passes

This record fails. It has an output mismatch and lacks enough identity evidence to attribute the mismatch to a particular saved source and interpreter.

Independent challenge: parcel status evidence

A parcel desk requires this exact output:

Parcel desk
Queue: training
Waiting:
5

Review the candidate source without running it:

print("Parcel desk")
print("Queue: training")
print("Waiting:")
print(2 + 3)

Produce a short review containing:

1. the predicted stdout, line by line;
2. the number of processes required for one run;
3. the channel expected to contain the four lines;
4. the expected exit status if no later error exists;
5. two identity fields still needed before accepting real run evidence; and
6. one sentence explaining why a screenshot of the four lines alone is insufficient.

Do not use Pocket Library wording in the answer. The changed context demonstrates that you can apply the evidence-chain model rather than recall one example.

Verification checklist

For any beginner script, collect or verify:

• [ ] the intended source file is saved;
• [ ] the source path is known;
• [ ] the selected interpreter and version are known;
• [ ] the process working directory and command are known;
• [ ] expected stdout is written before execution;
• [ ] expected stderr and exit status are stated;
• [ ] actual stdout, stderr, and exit status are captured from one run;
• [ ] actual and expected evidence are compared explicitly; and
• [ ] a clean exit is not substituted for requirement verification.

Later lessons automate parts of this checklist. The underlying reasoning remains the same.

Knowledge check

1. An editor contains a changed line that has not been saved. Which source does a terminal process normally read: the editor's unsaved document or the file on disk?
2. A script prints two lines and then reaches an uncaught runtime error. Can those two stdout lines exist even though the exit status is non-zero? Explain.
3. A process exits with status zero but prints 4 where the contract requires 3. Is the run successful, correct, both, or neither under the terms defined here?
4. Two Python processes use the same interpreter executable. Do they necessarily share the names created by their scripts?
5. Why is red text alone insufficient evidence that a message came from stderr?
6. Which evidence-chain link is missing when a record says only “I clicked Run and it worked”?

Common mistakes and their causes

Treating the terminal as the program

The terminal displays interaction with many processes. It is an interface and history surface, not the Python program itself. Identify which command created which process.

Trusting visible source without checking save state

Editors make unsaved text easy to overlook. A run reads a file or other supplied source, not your intention. Save deliberately and bind evidence to the saved artifact.

Calling any visible text “output”

Shell diagnostics, stdout, stderr, prompts, and earlier terminal history can appear together. Record channels and run boundaries rather than relying on appearance.

Equating zero with correctness

Exit status zero is a process result. Correctness is agreement with a requirement under declared conditions. A cleanly executed wrong calculation remains wrong.

Changing code before identifying the run

Editing the visible file does not help if another file or interpreter is being used. Collect identity evidence first, then make one change that tests a specific hypothesis.

Further reading and version notes

• Python 3.12 documentation, Using the Python Interpreter, distinguishes interactive use from script execution.
• Python 3.12 language reference, Execution model, is the authority for name binding and execution concepts that later modules develop.
• Python 3.12 library documentation, sys, defines the runtime interfaces later used to identify the executable and standard streams.

Full diagnostic wording and non-zero exit values can vary by platform, shell, and runtime build. The lesson relies on stable categories and evidence relationships rather than decorative formatting or one exact error-message rendering.

Key takeaways

• A saved file, selected interpreter, and running process are different things.
• One process produces evidence through stdout, stderr, and an exit status.
• Statements may produce output before a later runtime failure.
• A clean exit does not prove that the right file ran or that output met its contract.
• Trustworthy evidence binds the run to source, runtime, command, directory, expectation, and actual result.

Next step

You can now describe the parts of a run and reject evidence with missing identity. Next, you will make the interpreter executable and working directory observable without exposing a personal home path in submitted evidence.