Two Places Python Runs: This Page and Your Machine: Python Foundations

Outcome

By the end of this lesson you can look at a piece of Python work and say confidently whether it belongs in a short in-page exercise or in a real project on your own computer, and you can describe the record that the course-long project is built around.

Why it matters

This course runs small Python programs directly in your browser. That is genuinely useful: you can practise on a phone, on a train, with no installation and nothing to break. It is also genuinely limited. Real work reads files, installs libraries, talks to services, and lives in a folder you can back up.

Knowing which environment a task belongs in prevents two common frustrations: fighting the browser runner to do something it was never meant to do, and setting up a whole project to answer a three-line question.

Concept

The in-page runner starts a fresh Python interpreter inside your browser tab. It has the Python standard library and nothing else. It cannot reach the network, cannot read or write files on your computer, and forgets everything the moment the exercise resets. Each run gets a few seconds before it is stopped.

Those limits are the point. They make every exercise reproducible, keep your data on your device, and mean an accidental endless loop costs you one click instead of a reboot.

Work in the browser when the question is: does this line do what I think, what does this loop print, where is the bug, how do these two versions differ. Work locally when the task needs installed packages, real files, a database, a network call, more than a few seconds of computation, or more than one file of your own.

A useful rule: if you would want to keep it tomorrow, it belongs in a project on your machine.

Read the code

Everything in this course eventually points at one long project: a review assistant for public contracting opportunities of the kind published on SAM.gov, the United States government's public procurement site. The unit of data is an opportunity record. Here is a first sketch of one, written with nothing but names and values.

notice_id = "SPE-2026-0412"
title = "Grounds Maintenance, Building 7"
agency = "General Services Administration"
posted_date = "2026-03-04"
response_due = "2026-04-01"
set_aside = "Total Small Business"
estimated_value = 185000

print(f"{notice_id} | {title}")
print(f"{agency} | closes {response_due}")

Seven names, each holding one fact about one opportunity, and two lines that render a compact summary. notice_id is the stable identifier the publisher assigns; everything else is descriptive. set_aside records which category of business the work is reserved for, which is often the single field that decides whether an opportunity is worth reading at all.

Every later module makes this record more capable: rules that judge it, collections that hold many of them, functions that transform them, tests that pin their behaviour down, files and databases that store them.

Choose the workspace for the job

This page: short Python practice

Editor text

Fresh Python run → displayed result

Use it for: A small expression, loop or bug you can investigate in seconds.
Program state: Variables and temporary runtime files do not carry into the next run.
Resources: Use the provided runner; learner code cannot make network calls or open your computer’s files.

The page may retain an editor draft separately. A saved draft is not a saved Python session or a project backup.

Your machine: a local project

Saved project files

Local Python → results and files you choose to save

Use it for: Work across files or with installed packages, databases and network services.
Program state: A new Python process also starts fresh. Write data to files or a database when it must outlive the run.
Resources: Configure the interpreter, packages and permissions the project needs.

Save and back up your project explicitly. Local work does not become persistent merely because a program ran.

These limits describe this course’s in-page runner, not every browser-based Python tool. Start with short practice here; move work that needs lasting files or external resources into a local project. The opportunity record’s prediction remains yours to work out.

Predict the output

Write down the two lines you expect the program above to print, exactly, including the separators.

Check your prediction

SPE-2026-0412 | Grounds Maintenance, Building 7
General Services Administration | closes 2026-04-01

Three of the seven names, posted_date, set_aside, and estimated_value, are never printed. Creating a name costs nothing and produces no output; only print puts anything on screen.

Modify the code

Add a third print line that reports the set-aside category and the estimated value together, so a reviewer sees both without scrolling. Predict the line before you read on.

One way to write it, and what to notice

print(f"Set-aside: {set_aside} | Estimated ${estimated_value:,}")

That prints Set-aside: Total Small Business | Estimated $185,000. The record itself did not change; only the presentation did. Deciding what a reviewer needs to see, and in what order, is a real design decision, and it is separate from deciding what data you store.

Debug the bug

An assistant was asked to add the estimated value to the first summary line. It produced this, and claimed it prints the notice ID, the title, and the value.

notice_id = "SPE-2026-0412"
title = "Grounds Maintenance, Building 7"
estimated_value = 185000

print(f"{notice_id} | {title} | ${estimated value:,}")

What's wrong, and how you would have caught it

The last line writes {estimated value:,} with a space instead of {estimated_value:,} with an underscore. Python sees two words inside the placeholder where it expects one expression, cannot parse the file, and reports a syntax error before running a single line. Nothing prints, not even the working lines above it.

You would have caught this by running it, which is the cheapest check available and the one people skip when the code "looks right". A name with a space in it is not a name; the underscore is not decoration.

Try it yourself

Here is the same record with two fields that are stored but never shown. Add the lines that display the posted date and the set-aside category, so a reviewer can see when the notice appeared and who it is reserved for.

Loading this exercise…

Practical challenge (optional)

Optional: on paper or in a notes app, list three more fields you would want on an opportunity record before deciding whether to bid, and for each one write a single sentence saying what decision it changes. Keep the list. Module 6 asks you to turn a version of it into a written data dictionary, and a field you cannot justify in one sentence is usually a field you do not need.

AI collaboration

Checkpoint

Decide where each task belongs, an in-page exercise or a local project, and say why in one sentence:

Checking whether f"{value:,}" puts a comma in a five-digit number.
Reading 400 opportunity records from a file and writing a filtered list back out.
Working out why a loop prints one line too few.
Installing a library to talk to a public API.

Answers

In-page. One expression, no data, no dependencies, answered in seconds.
Local. It reads and writes real files, and you will want the output tomorrow.
In-page. Reading and running a short program is exactly what the runner is for.
Local. The browser runner cannot install packages or reach the network, by design.

Summary and next step

You now know what the in-page runner can and cannot do, when to move to a real project on your own machine, and what an opportunity record looks like as plain names and values. Module 1 turns those names and values into a working vocabulary: types, conversion, expressions, and formatted output, with the same record as the running example.