0.1From scripts to programs 🟢 Browser-safe

You finished Foundations able to write ~100-line programs: variables, loops, lists and dicts, functions, simple classes, files with try/except. This course takes you from there to 200–400-line tested, CLI-driven programs built from the standard library plus pytest. Same language — bigger workshop.

The loop stays — plus one new layer

Keep the Foundations habit verbatim: Read → Predict → Run → Tinker → Break → Fix → Build. Intermediate adds a layer between Predict and Run: Trace. Before running, ask "what is x at line N?" and work it out on paper. Solutions in this course show trace tables, not just answers.

What this course is not

Scope guard, stated once so no lesson smuggles these in: no async mastery, no metaclasses or descriptors, no Django/Flask production, no pandas/numpy track, no ML, no PyPI publishing pipeline (local pip install -e . at most). Suggestions in that direction belong in extensions.

Where you're headed

0.2Entry diagnostic — are you ready? 🟢 Browser-safe

Ten small tasks below, covering Foundations Modules 2–6. Rules: no hints, no peeking — do each from memory, then check against the solution. Count a task as passed only if your unaided version works.

• 7+/10: continue to Module 1.
• 5–6/10: skim the linked Foundations modules first (table below), then continue.
• Below 5: redo Foundations Modules 2–6 properly, then come back. Module 1 assumes all of this is fluent.

If you scored under 7 — revisit map

0.3Your two machines — browser and terminal 🔴 Terminal-required

This course runs on two machines: the browser tab you're in now, and the terminal on your own computer. Rule of thumb for the whole course: browser for concepts, terminal (or the desktop edition) for real files, CLIs, venv, and pytest. Every lesson wears one badge so you always know where you are:

Step 1 — check your Python

Open a terminal (Terminal on macOS/Linux/ChromeOS, PowerShell on Windows) and run:

Step 2 — one project, one venv

A venv is a private Python playground per project: its own packages, no interference between projects. Make one where you'll keep course work:

Step 3 — how a grown-up program is laid out

From Module 6 on, starters look like this — a folder, not a file. The browser shows them flattened; your PC uses the real tree:

Why the odd if? It means "run this only when the file is executed directly, not when imported for tests". Module 6 makes it second nature.

One more machine worth knowing: the desktop edition (python3 py-intermediate.py) sits between the two — same lessons, but code runs in a real subprocess with real files that persist in ~/.pyintermediate/workspace/. Browser for concepts, desktop/terminal for reality.

0.4Tracebacks — read the last line first 🟢 Browser-safe

You met tracebacks in Foundations; here they become your primary debugging tool. Anatomy of one — schematic, with notes where a real one names files:

Read bottom-up: the last line names the error type and cause; the frames above are the call chain that got there, outermost first. Then fix, rerun, repeat.

Module 0 done. You know what "intermediate" means, where you stand, where code runs, and how to read a crash. Module 1 starts the real upgrade: replacing loops with readable idioms.

1.1Comprehensions — loops in one line 🟢 Browser-safe

Module 1 replaces hand-written loops with readable idioms. First and most-used: the comprehension — a loop that builds a list, set, or dict in a single expression. Trace this one before running:

The shape is always [expression for item in source] — read it as "give me expression for every item". Same pattern builds the other containers, with an optional filter:

Nested — and when NOT to

Two loops nest left-to-right (same order as writing them out). Use it for genuinely flat transformations — and reach for a plain loop the moment a reader would squint:

1.2enumerate, zip, sorted — loops that count and pair 🟢 Browser-safe

Need an index? Don't count by hand — enumerate counts for you. Need two lists side by side? zip pairs them. Need order? sorted with a key beats every hand-rolled sort:

1.3Unpacking — *args and **kwargs 🟢 Browser-safe

Assignment can split a collection apart in one move. The star * soaks up "everything else" — in assignment, in calls, and in function signatures:

1.4Counter, defaultdict, namedtuple 🟢 Browser-safe

Three collections tools that delete whole categories of loop. You tasted Counter in Module 0 — here's the trio doing real grouping and record-keeping:

1.5Idioms — join, truthiness, any/all 🟢 Browser-safe

The small habits that mark intermediate code: build strings with join, lean on truthiness, ask any/all instead of flag variables:

1.6Checkpoint — quiz and exercises 🟢 Browser-safe

Five questions, then three builds. The quiz wants 4/5; the exercises want working code.

2.1First-class functions — plus lambda discipline 🟢 Browser-safe

First-class means functions are ordinary values: store them in dicts, pass them as arguments, return them from functions. The moment you stop seeing def as special syntax and start seeing functions as things you can hand around, a shelf of techniques opens:

And the tiny anonymous sibling — lambda makes a one-expression function with no name. Discipline matters more than syntax here:

2.2Closures — functions that remember 🟢 Browser-safe

A closure is a function that remembers variables from where it was born — even after that scope finished. State without a class, without globals:

2.3map/filter, itertools, functools 🟢 Browser-safe

map/filter apply a function to a pile — but after Module 1 you already own the clearer spelling. Rule: existing named function and no lambda needed → map is fine; otherwise the comp reads better:

itertools is the standard pile-plumbing kit. Three members cover 90% of uses — islice (take some, lazily), chain (one stream from many), groupby (runs of equal keys):

And functools: lru_cache memorizes pure functions, partial freezes some arguments to mint specialists. Note the spelling — calling lru_cache(...) on a function, no @ needed (that syntax is Module 7; this is the same machinery):

2.4Checkpoint — quiz and exercises 🟢 Browser-safe

Five questions, then three builds. Quiz wants 4/5.

3.1The iterator protocol — iter, next, done 🟢 Browser-safe

Every for loop you've ever written is sugar for three steps: iter() gets an iterator, next() pulls values, StopIteration ends it. Two roles: an iterable can make fresh iterators (lists, strings, files); an iterator is single-use and stateful:

The protocol in ten lines — __iter__ returns an iterator, __next__ returns values until it raises StopIteration (Module 4 explains dunders fully; here just watch the machinery):

3.2yield — ever-pausing functions 🟢 Browser-safe

A function with yield doesn't run when called — it returns a generator, paused at the top. Each next() resumes after the last yield and pauses at the next one. Nothing is computed until asked:

Pause-forever means infinite sequences are fine — as long as the consumer takes only what it needs. itertools.islice (Lesson 2.3) is the guard rail. This box is safe because of that last line:

One generator delegating to another uses yield from — "yield everything this produces", including cleaning up after it:

3.3Genexps and lazy pipelines 🟢 Browser-safe

Parentheses instead of brackets make a comprehension lazy — a genexp that yields values on demand and never builds the list. Same syntax, ~100x less memory:

The payoff: chain small generators into a pipeline — each stage transforms the stream, nothing lands in memory whole. Here with an in-memory stand-in for a file (Module 5 brings real ones):

Bridge to Module 7: generators with cleanup run their finally when close()d — even if the consumer quits early. contextlib.closing pairs them with with:

3.4Checkpoint — quiz and exercises 🟢 Browser-safe

Five questions, then three builds. Quiz wants 4/5.

4.1@dataclass — records without boilerplate 🟢 Browser-safe

Most classes are records: named fields, equality by value, readable repr. Hand-writing __init__ + __repr__ + __eq__ for every record is toil — @dataclass generates it from the field list:

Defaults are fine — except mutables, which need a factory. Plus frozen=True for immutable records:

4.2Dunders that pay — str, repr, eq, len 🟢 Browser-safe

Python has ~100 dunders; four earn their keep weekly. __str__ is for humans (print), __repr__ for developers (debuggers, containers, logs) — ideally an unambiguous echo of construction:

__len__ unlocks len() (and truthiness: empty means falsy). __eq__ compares by data — but it quietly disables hashing:

4.3Composition over inheritance 🟢 Browser-safe

Two ways to reuse behavior. Inheritance (IS-A): a subclass reuses and overrides. Composition (HAS-A): an object holds helpers and delegates. Inheritance is taught first and reached for most — composition wins more often. The tell: new behavior as a new subclass per combination (DiscountedCart, TaxedCart, DiscountedTaxedCart…) versus a policy plugged into one class:

Inheritance earns its place for shared interfaces with substitution: an Admin IS-A User wherever login code expects a User, honoring the same method contracts. Foundations' Student(Person) qualifies — a student can stand in for a person. A cart with discount options doesn't: that's configuration wearing a subclass costume. Heuristic: reach for composition first; inherit only when callers should treat the child as the parent.

4.4@property — validated attributes 🟢 Browser-safe

Plain attributes accept anything (score.points = -40 — sure, why not). @property keeps the obj.attr syntax but routes access through methods — validation at the boundary, with storage in a private backing field:

4.5Custom exceptions — raise from 🟢 Browser-safe

Domain errors deserve domain types: callers catch the meaning (OverdraftError), not ValueError soup they can't distinguish from bugs. And raise ... from ... chains the cause, so tracebacks tell the full story:

4.6Checkpoint — quiz, lab, exercises 🟢 Browser-safe

Five questions, one refactor lab, two exercises. Quiz wants 4/5; the lab is the real exam.

5.1pathlib — paths as objects 🟡 Browser-adapted

🟡 Browser-adapted: identical code both places — but this tab's files live in memory and vanish on close, while your PC keeps them in ~/.pyintermediate/workspace/ (desktop) or your project folder (terminal).

Stop gluing strings with + "/" +. A Path joins with /, knows its own name/suffix, and reads/writes in one call. This module's arc: a garden journal stored as date|text lines, upgraded lesson by lesson to JSON, then SQLite:

5.2csv — commas are trickier than they look 🟡 Browser-adapted

🟡 Browser-adapted: same code, same output — on your PC the file persists for the next lesson; here, rerun the writer if you jumped in mid-module.

"rain, no watering".split(",") gives three fields from two — quoted commas, embedded newlines, and quotes defeat hand-splitting. The csv module handles all of it, including our pipe-delimited journal via delimiter:

5.3json — the lingua franca 🟡 Browser-adapted

🟡 Browser-adapted: same JSON everywhere — but fetching it differs: this tab uses browser-native pyfetch, your PC uses requests. The parsing below is identical.

JSON is how programs trade data: dicts/lists ↔ text. dumps/loads work with strings, dump/load with files. Our journal, upgraded from pipes to structure:

5.4sqlite3 — a database in one file 🟡 Browser-adapted

🟡 Browser-adapted: :memory: databases behave identically everywhere. For persistence, swap in a filename — on your PC it becomes a real .db file; here, download it via the snippet in the prose.

SQLite is a full SQL database in a library — no server, one file, zero setup. Same journal, third upgrade: queryable rows instead of scanned text. Two non-negotiables: ? placeholders (never f-strings — injection and quoting bugs) and commit():

Persistence note: replace ":memory:" with "journal.db" and the database outlives the session — on desktop it lands in ~/.pyintermediate/workspace/; in this tab, files vanish on close, so treat the browser as the rehearsal and your PC as the archive.

5.5Cleaning dirty data — regex and dates 🟢 Browser-safe

Real data arrives filthy: ragged spacing, N/A where dates belong, quotes inside quotes. Two tools carry the cleaning shift — re for shape, datetime for time. The essentials, no more: search (anywhere), match (start only), findall (every hit):

Dates: strptime parses, isoformat stores — and naive datetimes (no zone) refuse to compare with aware ones. Parse, then stamp a zone immediately:

5.6Checkpoint — quiz and exercises 🟢 Browser-safe

Five questions, then three builds. Quiz wants 4/5.

6.1Project setup — layout, venv, pip 🟡 Browser-adapted

🟡 Browser-adapted: concepts + transcripts here; the one runnable box uses the browser's micropip (desktop shows it as reference). Real venv/pip happen in your terminal, inside the pywork folder from Lesson 0.3.

Professional layout, full tour — one folder per program, tests beside code, dependencies written down:

In this tab there is no pip — but Pyodide ships micropip, real packages from real PyPI (internet needed). Same packages your terminal gets:

6.2argparse — programs with a command line 🟢 Browser-safe

Buttons are for browsers; real tools take arguments. argparse turns a function call into a CLI with --help, types, choices, and defaults — free. The browser has no command line, so lessons use an ARGS stand-in (desktop/terminal call parse_args() bare for the real thing):

Types convert, choices reject, and rejections raise SystemExit (not a normal exception — it carries the process exit code):

6.3logging — prints with levels 🟢 Browser-safe

print debugging litters shipped code with chatter you can't switch off. logging gives every message a level — one dial (basicConfig(level=...)) decides what shows, per run, without touching code:

6.4pytest — tests that guard your back 🔴 Terminal-required

🔴 Terminal-required: pytest runs on your PC (python -m pytest in the venv). This lesson's runnable boxes are the code under test (plain asserts run anywhere); the pytest runs themselves are transcripts — a passing run is never faked in-browser.

The whole framework in one habit: write the expectation as a bare assert in a test_*.py file, run, read failures. Start with the code — assertions hold here exactly as they hold under pytest:

Same assertions, dressed as a test file, run for real:

Read failures like tracebacks: the > line is the expectation, E lines are the evidence (1000000.0 == 1000000 — a float/int strictness lesson for free). Now the test-writing trap:

6.5Checkpoint — quiz and exercises 🟢 Browser-safe

Five questions, then three builds. Quiz wants 4/5.

7.1Decorators — functions that upgrade functions 🟢 Browser-safe

After Modules 2 (first-class functions) and 3 (pausing functions), the power tools unlock. A decorator is Lesson 2.1 grown up: a function that takes a function and returns an enhanced one. The @ is pure sugar — @timer above a def just means "reassign the name through timer":

Decorators take arguments via a factory (a function returning the decorator), and they stack bottom-up — the closest one runs first:

7.2Context managers — setup, use, guaranteed cleanup 🟢 Browser-safe

with open(...) was your first context manager: setup, use, guaranteed cleanup. Custom ones come in two spellings — the class (__enter__/__exit__) and the generator (@contextmanager, pure Module 3):

7.3Combined — timed, retried, logged 🟢 Browser-safe

The graduation exercise: both tools on one job. Small composable pieces — a @retry decorator, a timed context — around a flaky operation (simulated: no network needed). Notice the layers stay independent and testable:

Modules complete. Three capstones remain: a CLI file tool, a CSV→SQLite reporter, and a tested mini-API — each one a 200–400-line portfolio program built from everything above.

8.1Capstone A — CLI file tool (jstat) 🔴 Terminal-required

🔴 Terminal-required (with 🟢 flattened preview below — the whole tool in one runnable box; the real thing is three files you build on your PC).

Spec. jstat reads a garden journal (date|text lines, Module 5) and reports: entry count, distinct words, top-N words. python main.py journal.txt --top 3 --verbose must exit 0 and log its steps; missing file exits 2 with a clean error, never a traceback.

Build order.

1. journal.py — pure load + stats (no I/O inside; testable!).
2. tests/test_journal.py — three asserts; run python -m pytest after every step.
3. main.py — thin shell: argparse, logging, file read, print report.
4. Break it: empty file, missing file, 10k-line file. Fix, extend (below).

🚀 Extensions (optional): +feature: --by-date flag printing entries-per-day (Counter over dates). +robustness: skip malformed lines with a warning (Lesson 5.5). +ship: pip install -e . + a console entry point so jstat runs bare.

8.2Capstone B — CSV to SQLite reporter 🔴 Terminal-required

🔴 Terminal-required (with 🟢 flattened preview below — the pipeline in one runnable box; the real thing is three files + a real .db on your PC).

Spec. sales.csv (date,product,qty,price) in, revenue report out: per-product revenue ranked, top day overall. Dirty rows (bad numbers, missing fields) are skipped with a warning, never fatal. The DB file persists between runs.

Build order.

1. report.py — pure clean + totals (dicts in, dicts out).
2. tests/test_report.py — dirty-row skip, revenue math, empty input.
3. main.py — argv (in-csv, out-db), logging, load → SQLite → print.
4. Feed it 10k generated rows; watch it stay flat in memory (generators, Lesson 3.3).

🚀 Extensions (optional): +feature: --by-day full daily table. +robustness: stream the CSV with generators (never list(reader)). +ship: argparse.FileType vs manual open — compare error messages.

8.3Capstone C — tested mini-API 🔴 Terminal-required

🔴 Terminal-required (with 🟢 flattened preview below — the pure routing core runs here; sockets need your PC).

Spec. A JSON API over http.server (stdlib only): GET /players lists, GET /players/NAME fetches, unknown → 404 JSON. The routing core is pure ((method, path) → (status, body)) and pytest-tested; the HTTP shell is thin.

Build order.

1. api.py — pure route(), no sockets, no globals mutated in surprising ways.
2. tests/test_api.py — list, fetch, 404s; green before any networking.
3. server.py — 30-line BaseHTTPRequestHandler shell calling route.
4. curl every route; add POST as the extension.

🚀 Extensions (optional): +feature: POST /players with a JSON body (parse Content-Length, validate, 201). +robustness: log every request with Lesson 6.3 levels (INFO hits, WARNING 404s). +ship: persist STORE to SQLite (Lesson 5.4) so players survive restarts.

AAppendix A — regex quick reference 🟢 Browser-safe

Everything Lesson 5.5 taught, on one screen. Static reference — nothing to run.

BAppendix B — itertools cheat sheet 🟢 Browser-safe

Lessons 2.3 and 3.3 introduced the big three; the rest of the kit, same lazy deal — everything returns iterators, nothing builds lists. Static reference.

CAppendix C — field guide and where next 🟢 Browser-safe

The errors you'll meet weekly, the commands you'll type daily, and the roads after this course. Static reference.

Error → meaning → fix

Terminal daily drivers

Where next — three lanes

Scope, one last time: async mastery, metaclasses/descriptors, production web, pandas/numpy tracks, ML, and PyPI publishing are beyond this course by design — each lane above teaches them in its own good time. What this course promised was 200–400-line tested programs from stdlib + pytest. You have three of those now. Go build the fourth.