Data & Structures

1 · Lists essential

Here's a thing that surprises people the first time they see real LLM code. You imagine an AI conversation as some exotic object — and then you open the code and it's just a list. A plain Python list, the same one you'd use for a shopping list, holding the whole chat: [first message, model's reply, your next message, …]. Once that clicks, half of this course stops looking like magic and starts looking like moving items in and out of a list. That's the whole reason this is the very first section.

Think of a list as a numbered row of lockers. The lockers sit in order, you can open any one by its number, and you can keep bolting new lockers onto the end. Two ideas do all the work. First, it's ordered: item 0 is always item 0, and the order you put things in is the order they stay in — which matters enormously for a conversation, where "who said what, and when" is the entire point. Second, it's changeable (the jargon is "mutable"): you can add to it, overwrite a slot, or remove from it after it's built, which is exactly what an agent does as it appends each new turn.

Why it matters: in this course a list is what messages, a response's content blocks, your tools, and every batch of search results actually are. When you loop over them, slice off "the last N", or .append() a new turn, you're doing the single most common operation in the whole codebase. Get comfortable here and the agent loop reads like plain English later.

Name the common mistake now, because everyone hits it: Python counts from zero, not one. The first item is pods[0], and the last of three items is pods[2], not pods[3] — reach for pods[3] on a three-item list and Python stops you with an IndexError. That "off-by-one" is the most common beginner bug in any language, and the friendly fix is pods[-1]: negative indices count from the end, so -1 is always the last item no matter how long the list grew. With that in mind, here's the everyday toolkit.

pythonpods = ["checkout-api", "web-frontend", "worker-queue"]

pods[0]              # 'checkout-api'  (first — zero-indexed)
pods[-1]             # 'worker-queue'  (last)
pods[:2]             # ['checkout-api', 'web-frontend']  (a "slice")
len(pods)            # 3
pods.append("db")     # add to the end
"web-frontend" in pods   # True

for p in pods:         # loop over items
    print(p)

2 · Dictionaries essential

Imagine trying to find one word's meaning in a paper dictionary by starting at page 1 and reading every entry until you hit it. Absurd — you'd flip to roughly the right place and jump. That's the whole idea behind Python's dictionary: you don't hunt through positions, you look things up by name. Ask for msg["role"] and it hands you the value straight away, without walking past everything else. It's named after the book for exactly this reason — a real dictionary maps a word to its definition; a Python dict maps a key to a value.

If a list answers "what's at position 3?", a dict answers "what's stored under this label?" — and that's a far more natural question when your data has named parts. A chat message isn't naturally "item 0 and item 1"; it's "a role and some content". A dict lets you say that directly: {"role": "user", "content": "What's broken?"}. The picture to hold in your head is a coat-check counter: you hand over a ticket (the key) and get back exactly your coat (the value), instantly, no matter how many coats are on the rack.

Why this earns "essential": just about every structured thing in this course is a dict. A message is a dict. A tool result is a dict. An API object is a dict. Whole responses are dicts nested inside dicts. If lists are the rows of the course's data, dicts are the records — and you'll spend more time reading and building them than anything else.

The mistake that will bite you, and the habit that prevents it: looking up a key that isn't there. Writing msg["role"] when there is no "role" key doesn't quietly return nothing — it crashes your program with a KeyError. That's fine when you're certain the key exists, but real data from tools and APIs is often missing fields. The safe alternative is msg.get("role"), which returns None (or a default you name, like msg.get("ns", "staging")) instead of blowing up. A good rule of thumb: use square brackets when the key must be there and its absence is a real bug; use .get() with a sensible default when the key is optional. You'll see p.get("logs", []) all over the capstone for exactly this reason.

pythonmsg = {"role": "user", "content": "What's broken?"}

msg["role"]                 # 'user'  (look up by key)
msg.get("missing")          # None  (safe: no error if key absent)
msg.get("ns", "staging")     # 'staging'  (default if absent)
msg["content"] = "updated"   # change a value
msg.keys()                  # dict_keys(['role', 'content'])

for key, val in msg.items():   # loop over pairs
    print(key, "=", val)

3 · Nested data — the real shape of API objects essential

The first time you print a real API response, your heart sinks a little. It's a wall of braces and brackets, keys inside lists inside keys, scrolling off the screen. Everyone's instinct is to try to hold the whole thing in their head at once — and everyone fails, because you can't. The good news is that you never have to. Nested data only looks scary; it's read the same calm way every time, and this section is about that one reliable trick.

Here's the mental model: nested data is a set of Russian nesting dolls, or rooms opening into rooms. Each layer is just a list or a dict — the same two things you already know from §1 and §2 — sitting inside another list or dict. A dict whose value is a list of dicts (each of which has a list inside it) sounds like a tongue-twister, but it's only lists and dicts stacked up. Nothing new to learn; the skill is navigation, not new vocabulary.

Why this is essential and not optional: this is the literal shape of the data you'll spend the course handling. kubectl get -o json, the capstone's fixtures.json, an LLM response object, a page of search hits — all of them are lists-inside-dicts-inside-lists. You cannot read state from a real system without reading nested data, so this is the bridge between "toy examples" and "actual work".

The trick, and the mistake it cures: read it one bracket at a time, left to right — never try to swallow the whole path in one gulp. The beginner error is to stare at state["pods"][0]["logs"][-1] as one intimidating blob and freeze. Instead, walk it: state["pods"] is "the list of pods"; add [0] and you have "the first pod" (a dict); add ["logs"] and you have "that pod's log list"; add [-1] and you have "its last line". Each step lands you on a plain list or dict you already understand, so at every point you can pause and ask "what do I have right now?" Build the path outward one piece at a time and the wall of brackets turns into a short, obvious walk.

pythonstate = {
  "pods": [
    {"name": "checkout-api", "status": "CrashLoopBackOff",
     "logs": ["starting", "auth failed"]},
    {"name": "web", "status": "Running", "logs": []},
  ]
}

# read it step by step:
state["pods"]                 # the list of pod dicts
state["pods"][0]              # the first pod dict
state["pods"][0]["name"]      # 'checkout-api'
state["pods"][0]["logs"][-1]  # 'auth failed'

4 · Tuples & sets intermediate

You already have lists and dicts — so why meet two more collections? Because sometimes a list is subtly the wrong tool, and using the right one makes a bug impossible or a slow program fast. Tuples and sets aren't exotic; they're a list with one deliberate feature added or removed. Learn what each one gives up, and you'll know instantly when to reach for it.

Start with the tuple. A tuple is simply a list that has been locked — once created, you can't change it. Think of a list as a whiteboard you keep editing, and a tuple as something printed on paper: fixed, final, safe to hand around. Why would you want to give up the ability to edit? Because some groupings shouldn't change: an (x, y) coordinate, an (chunk, score) pair returned from a search, a row from a database. Locking it says "these belong together and shouldn't be tampered with", and it lets Python use tuples as dictionary keys (lists can't be keys, because they might change under the dict's feet). You'll meet tuples most often through unpacking — chunk, score = result — which splits a two-part group into two names in one clean line.

Now the set. A set is a collection with two rules: no duplicates, and no order. Picture a bag of unique name-tags — adding a tag that's already inside changes nothing, and there's no "first" or "last". That sounds limiting until you see the payoff: because a set is built on the same hashing trick as a dict's keys, asking "is x in here?" is nearly instant even for millions of items, where the same check on a list has to scan every element one by one. So the moment your code is testing membership repeatedly — "have I seen this id?", "is this tool in my gated list?" — a set is dramatically faster than a list.

The mistake to avoid: treating a set like a list and expecting order or positions. There's no my_set[0] — sets don't index, because they don't have an order. And don't try to mutate a tuple: point[0] = 5 raises a TypeError, which is the tuple doing its job, not a failure. Match the container to the need: list for an ordered, editable sequence; tuple for a fixed group; set for fast uniqueness and membership.

python# tuple: an ordered group that can't change (parentheses)
point = (0.1, 0.9)
chunk, score = ("faq.md#0", 0.87)   # "unpacking" into two names

# set: unique items, fast membership test (curly braces, no keys)
seen = {"a", "b"}
seen.add("a")          # still {'a','b'} — duplicates ignored
"a" in seen           # True (very fast)
DESTRUCTIVE = {"delete_pod", "terraform_apply"}   # a set of gated tools

5 · Comprehensions — the course's favorite one-liner intermediate → essential

The first time you see a comprehension, it looks like someone smashed a loop flat and hoped for the best. [p["name"] for p in pods if p["status"] != "Running"] — all on one line, no colon, no indentation. It's the single most common "wait, what does that do?" moment for people reading this course's code. So let's demystify it completely, because once it clicks you'll not only read the course fluently, you'll start writing it yourself.

A comprehension is just a for-loop that builds a list, folded onto one line. That's the entire idea. Any time you'd write "make an empty list, loop over something, append a transformed item each time", you can say the same thing in one expression. The trick to reading it is to read it out of order: find the for in the middle first ("for each pod in pods"), then the if on the right if there is one ("keeping only the ones not Running"), then the bit on the left that says what to collect ("grab its name"). Left-thing, for-each-item, optional-filter — that's the rhythm, and it matches plain English: "the name of each pod that isn't running."

Why the course leans on it so hard: almost everything here is "take a list, keep some of it, transform each survivor" — pull the names out of pod dicts, keep only the failing ones, build a tool spec from each tool, turn chunks into a lookup table. A comprehension expresses that in a line you can read at a glance, instead of a four-line loop you have to trace. There are three flavours you'll meet: the plain list comprehension, the dict comprehension ({key: value for …}, which builds a lookup instead of a sequence), and the same syntax feeding any()/all() to answer a yes/no question over a collection.

The mistake to watch for — and the honest limit: comprehensions are for building a collection, not for doing side-effects. If your loop body is really about calling print() or writing to a file rather than collecting values, keep it a normal loop; cramming that into a comprehension is a well-known code smell. And resist the urge to nest three of them deep to look clever — past a certain point a plain loop is clearer, and clarity always wins. Use a comprehension when it makes the intent more obvious, which, for the filter-and-transform work in this course, is nearly always.

pythonpods = [{"name":"a","status":"Running"}, {"name":"b","status":"CrashLoopBackOff"}]

# the long way
names = []
for p in pods:
    names.append(p["name"])

# the comprehension (same result, one line)
names = [p["name"] for p in pods]                    # ['a', 'b']

# with a filter
broken = [p["name"] for p in pods if p["status"] != "Running"]   # ['b']

# dict comprehension
by_name = {p["name"]: p for p in pods}              # look up a pod by name

# any() / all() with a comprehension — common in tests
any(p["status"] == "CrashLoopBackOff" for p in pods)   # True

6 · JSON & files essential

Here's a problem you don't notice until you hit it. You've built a lovely dict of state in memory — but the moment your program ends, it's gone. And when an API on the other side of the internet wants to send you a nested structure, it can't ship you a live Python object down the wire; it can only send text. So you need a way to flatten your dicts and lists into plain text you can save to a file or send across a network — and to rebuild them on the other side. That format is JSON, and it's everywhere in this course precisely because it solves this everyday problem.

The beautiful thing about JSON is how little you have to learn: it maps almost 1:1 onto the lists and dicts you already know. A JSON object {...} becomes a Python dict; a JSON array [...] becomes a list; strings, numbers, true/false become str, numbers, True/False. Think of JSON as the "flat-packed furniture" version of your data — the same table, disassembled into a box for shipping, that reassembles into the identical table when unpacked. That's why fixtures, configs, and API payloads all live as JSON: it's the universal shipping format for structured data.

The one naming trap that confuses everybody, so learn it once and never trip again: the json module has two nearly-identical pairs of functions, and the difference is a single letter s for "string". json.load(f) reads from a file; json.loads(text) reads from a string. Likewise json.dump(obj, f) writes to a file, and json.dumps(obj) returns a string. Read the trailing s as "string" and the whole module suddenly makes sense: no-s talks to files, s talks to strings.

Reading files uses the with open(...) pattern, and it's worth a word on why it looks the way it does. A file is a limited resource the operating system hands you — leave it open and you leak it; forget to close it after writing and your data may never actually hit the disk. The with block guarantees the file is closed for you the instant you leave it, even if an error is thrown midway. You'll learn the machinery behind this (context managers) in P4; for now, just always read and write files inside a with open(...) and you'll never leak a file handle or lose a half-written file.

pythonimport json

# read a JSON file into Python objects
with open("fixtures.json") as f:
    state = json.load(f)          # dict/list, ready to use

# parse a JSON string (e.g. a tool's output)
data = json.loads('{"replicas": 3}')   # {'replicas': 3}

# turn Python back into a JSON string (e.g. a log line)
line = json.dumps({"trace_id": "abc", "tokens": 42})

# read a whole text file (a runbook)
with open("crashloop.md") as f:
    text = f.read()

7 · Just enough regex intermediate

Regular expressions have a fearsome reputation, and it's half-deserved. You've probably seen one of those line-noise monsters — ^(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@… — and quietly decided regex is not for you. Here's the reassuring truth: for this whole course you need about four tiny patterns, and they're genuinely easy. We're going to learn "just enough" on purpose, and skip the wizardry that gives regex its scary name.

So what is a regular expression? It's a search pattern for text — a way to describe "find things that look like this" instead of hunting for one exact word. Ordinary "error" in line only finds the literal word "error"; a regex can find "any run of digits", "any word", or "three digits, a dash, two digits, a dash, four digits" (a US Social Security number). Think of it as a stencil you lay over text: wherever the shape lines up, that's a match. The pattern is written in a little mini-language, but you only need a handful of its symbols.

Why it earns a place in a data chapter: real inputs arrive as messy text, not tidy dicts. Log lines, documents, and user messages are strings, and before you can put them into lists and dicts you often have to carve them up — split a document into paragraphs to chunk it for RAG, pull the numbers out of a status line, or scan for a pattern that looks like leaked personal data (PII) so you can redact it. That carving is what a little regex buys you.

The pieces to actually memorise are few: \w+ means "one or more word characters" (letters, digits, underscore) — that's how you grab words; \d+ means "one or more digits" — that's how you grab numbers; and \b is a "word boundary" — the invisible edge between a word and a space, so a pattern doesn't accidentally match inside a longer run. That's roughly 90% of what you'll ever type. One habit that prevents a whole class of bugs: always write regex patterns as raw strings with an r in front — r"\w+", not "\w+". Without the r, Python tries to interpret the backslashes itself before the regex engine ever sees them, and your pattern quietly breaks. The r says "hands off, pass these backslashes through untouched", and making it automatic will save you a confusing afternoon.

pythonimport re

re.findall(r"\w+", "reset my password")     # ['reset','my','password'] — words
re.findall(r"\d+", "3 pods, 7 restarts")      # ['3','7'] — numbers
re.split(r"\n\s*\n", text)                 # split on blank lines (paragraphs)
re.search(r"\b\d{3}-\d{2}-\d{4}\b", s)     # find an SSN (PII redaction)

8 · List methods & sorting essential

Every retrieval system, every search box, every "best results first" list you've ever used comes down to one operation: sorting. When a RAG pipeline pulls back forty candidate chunks and shows the model only the top three, that's a sort followed by a slice. When re-ranking re-orders results by a better score, that's a sort. If you learn one thing from this section, make it sorted() with a key — it's the quiet workhorse behind more of this course than any other single function.

Basic sorting is obvious enough — sorted([0.2, 0.9, 0.5]) gives you the numbers in order. The leap that unlocks real work is the key argument, so let's make sure it lands. Imagine a stack of résumés you want ordered by years of experience. You don't compare the whole résumé; you glance at one number on each and sort by that. key is exactly that glance: it's a little function that, given one item, returns the value to sort on. So sorted(chunks, key=lambda c: c["score"]) means "for each chunk, look at its score, and order by that" — the chunks come back ranked even though you sorted a list of complicated dicts. (A lambda is just a throwaway one-line function; lambda c: c["score"] reads "given c, give back c's score".)

Two companions complete the pattern. reverse=True flips ascending into descending — and for scores you almost always want the biggest first, so this shows up constantly. And slicing [:k] takes the top k after sorting. Put them together — sorted(items, key=..., reverse=True)[:k] — and you've written the "top-k" funnel that is retrieval: over-fetch a pile of candidates, rank them, keep the best few. That one line is worth committing to muscle memory.

The mistake that surprises newcomers: the difference between sorted(x) and x.sort(). sorted() returns a new list and leaves the original untouched — safe, and what you usually want. x.sort() reorders the list in place and returns None, which trips people who write y = x.sort() and are baffled when y is None. When in doubt, reach for sorted(); it never mutates data out from under you. The other classic gotcha: sorting mixed types (numbers and strings together) raises a TypeError — Python refuses to guess how a 3 compares to "three", and that strictness is a feature, not a bug.

pythonscores = [0.2, 0.9, 0.5]
sorted(scores)                 # [0.2, 0.5, 0.9] — ascending (new list)
sorted(scores, reverse=True)   # [0.9, 0.5, 0.2] — descending

# sort a list of dicts by a field — the key is a function of each item
chunks = [{"id":"a","score":0.2}, {"id":"b","score":0.9}]
ranked = sorted(chunks, key=lambda c: c["score"], reverse=True)
top3 = ranked[:3]              # take the best 3 (the retrieval funnel)

# sort scores but remember original positions (argsort-style)
order = sorted(range(len(scores)), key=lambda i: -scores[i])   # [1,2,0]

# other handy methods
scores.index(0.9)              # 1  — position of a value
[1,2,2,3].count(2)         # 2  — how many times it appears
list(reversed([1,2,3]))       # [3,2,1]

9 · enumerate & zip essential

Watch a beginner loop when they also want the position, and you'll see the tell-tale move: they create a counter variable, i = 0, then remember to write i += 1 at the bottom of the loop — and half the time they forget, or increment it in the wrong place, and the numbering goes sideways. Python has a cleaner way, and once you meet it you'll never hand-roll a counter again. The two helpers in this section, enumerate and zip, exist to kill two of the fiddliest, most error-prone loop patterns there are.

enumerate hands you the position and the item together. Instead of "loop over the items and separately track where you are", you write for i, item in enumerate(things): and Python gives you both, correctly, every time. Picture a teacher walking down a row of students calling out "one, two, three" — the count and the student arrive as a pair, automatically. A lovely touch: enumerate(things, 1) starts the count at 1 instead of 0, which is exactly what you want when the numbers are for humans to read — like the [1] [2] [3] citations RAG builds so the model (and the reader) can point at a source.

zip walks two lists in lockstep. When you have parallel lists — names = ["cpu","mem"] and values = [17, 96] — the clumsy way is to loop over indices and write names[i] and values[i] everywhere, which is noisy and easy to mis-index. zip zips them together like a zipper's two rows of teeth meshing: for name, val in zip(names, values): pairs the first with the first, the second with the second, and hands you both. It's also the tidiest way to build a dict from two lists — dict(zip(names, values)) — which you'll do whenever keys and values arrive separately.

The one surprise to file away: zip stops at the shortest list. If names has three entries and values has two, zip gives you two pairs and silently drops the extra name — no error. That's occasionally handy but more often a bug waiting to happen, so when you zip two lists that are supposed to be the same length, it's worth a quick check that they actually are. Beyond that, these two are pure quality-of-life: they make loops read like sentences instead of index arithmetic.

pythonchunks = ["first", "second", "third"]

# enumerate: index + item. start=1 for human-friendly numbering.
for i, text in enumerate(chunks, 1):
    print(f"[{i}] {text}")      # [1] first  [2] second  [3] third

# this is how RAG builds its numbered, citable context:
context = "\n".join(f"[{i}] {c}" for i, c in enumerate(chunks, 1))

# zip: iterate two (or more) lists together
names = ["cpu", "mem"]
values = [17, 96]
for name, val in zip(names, values):
    print(f"{name}={val}")     # cpu=17  mem=96

dict(zip(names, values))         # {'cpu': 17, 'mem': 96} — build a dict from two lists

10 · defaultdict & Counter — grouping & counting intermediate

Two tasks come up so often that Python ships purpose-built tools for them, and most people re-invent both — badly — before discovering they exist. The first is counting: "how many ERRORs, how many WARNs?" The second is grouping: "collect all the messages under each service." You can do both with a plain dict, but the hand-rolled version is clumsy and has a lurking bug. This section is about the two tools from the collections module — Counter and defaultdict — that make each a clean one-liner.

Consider grouping the naive way. You want {"api": ["boom", "again"], "web": ["503"]}, so you loop and write groups[svc].append(msg) — and it crashes the very first time it meets a new service, because that key doesn't exist yet and you can't append to a value that isn't there. So you sprinkle in a guard: "if this service isn't in the dict yet, first set it to an empty list." It works, but every grouping loop you ever write carries that same tedious three-line dance. That repeated "check-if-missing-then-initialise" is precisely the friction these tools remove.

defaultdict is a dict that auto-creates a starting value for any key you touch. Tell it defaultdict(list) and a missing key springs to life as an empty list [] the moment you reach for it — so by_service[svc].append(msg) just works, first time and every time, no guard needed. Think of it as a filing cabinet that quietly opens a fresh empty folder whenever you file under a new label. Use defaultdict(int) and missing keys start at 0 (perfect for counting), defaultdict(float) starts at 0.0 (perfect for accumulating scores, exactly how the course's RRF fusion sums ranks).

Counter is a specialised dict that does the whole tally in one call. Hand it any list and Counter(levels) returns each distinct value with its count already computed; .most_common(3) then hands back the top three as ranked pairs, saving you a sort. The mistake to avoid is doing this the long way — writing your own count-and-sort loop when Counter already exists and is both faster and clearer. The rule of thumb: the instant you catch yourself writing "if the key is missing, initialise it, then add to it", stop — defaultdict or Counter is the tool you actually want.

pythonfrom collections import defaultdict, Counter

# Counter: tally occurrences (e.g. error types in logs)
levels = ["ERROR", "INFO", "ERROR", "WARN", "ERROR"]
counts = Counter(levels)         # Counter({'ERROR': 3, 'INFO': 1, 'WARN': 1})
counts["ERROR"]                  # 3
counts.most_common(2)           # [('ERROR', 3), ('INFO', 1)]

# defaultdict: group items without checking "does the key exist yet?"
logs = [{"svc":"api","msg":"boom"}, {"svc":"api","msg":"again"},
        {"svc":"web","msg":"503"}]
by_service = defaultdict(list)   # missing keys auto-start as []
for l in logs:
    by_service[l["svc"]].append(l["msg"])
# {'api': ['boom','again'], 'web': ['503']}

# the scoring pattern from RRF uses the same idea:
scores = defaultdict(float)
for rank, cid in enumerate(["a","b","a"]):
    scores[cid] += 1 / (60 + rank)   # no "if cid in scores" needed

11 · Robust JSON — handling messy real data intermediate

Here's a 2 a.m. story that every agent builder eventually lives. Your agent has run flawlessly in testing for a week. Then a model returns tool arguments with a stray trailing comma, or an API omits a field that "always" used to be there, and your beautiful pipeline dies with a stack trace — mid-conversation, in front of a user. Nothing was wrong with your logic. The world just handed you data that wasn't as clean as your tests. This section is the small set of habits that keep that night from happening.

The core mindset shift is this: in §6 you learned to parse JSON assuming it's valid. In the real world, you must assume it might not be. Data arriving from a model, a network call, or a file you didn't write is untrusted — it can be malformed (not valid JSON at all) or merely incomplete (valid, but missing the key you need). Treating every external input as guilty-until-proven-innocent is the difference between a toy script and code you'd let run unattended.

Two techniques handle almost everything. The first is guarding the parse: wrap json.loads(text) in a try / except json.JSONDecodeError so that garbage input returns a tidy None (or an error object) instead of crashing the whole program. Think of it as a seatbelt — it doesn't stop the pothole, it stops the pothole from throwing you through the windscreen. The second is digging safely through nested data with chained .get() calls: data.get("status", {}).get("phase", "Unknown") reaches two levels down and, if either level is missing, calmly falls back to a default rather than raising a KeyError. Each .get with an empty-dict default keeps the next step alive.

One habit here quietly saves real money, and it surprises people, so it's worth calling out: when you serialise JSON that goes into a cached prompt prefix, pass sort_keys=True. Why? Prompt caching keys on the exact bytes of the prefix, and Python doesn't guarantee dict key order matches between runs — so an unsorted json.dumps() can emit the same data in a different order, change the bytes, and silently miss the cache you were paying to hit. Sorting the keys makes the output deterministic: identical data always produces identical text. It's a one-word habit (covered again in Ch 6) with an outsized payoff — the recurring lesson of this section is that robustness is a collection of small, cheap habits, not one heroic fix.

pythonimport json

# 1. guard the parse — model/tool output isn't always valid JSON
def safe_parse(text):
    try:
        return json.loads(text)
    except json.JSONDecodeError:
        return None          # caller decides what to do

# 2. dig safely through nested data that might be missing keys
data = {"status": {"phase": "Running"}}
phase = data.get("status", {}).get("phase", "Unknown")   # 'Running', never KeyError

# 3. pretty-print for logs / debugging; sort keys for stable output
print(json.dumps(data, indent=2, sort_keys=True))

# 4. write JSON to a file
with open("out.json", "w") as f:
    json.dump(data, f, indent=2)

Worked example · a log analyzer putting it together

Individual skills are one thing; the real test is whether they combine into something useful. So far each section taught one tool in isolation — a comprehension here, a Counter there. That's how you learn, but it's not how you work. Real code weaves several of these together in a handful of lines to answer a genuine question. This worked example does exactly that: it takes a pile of raw log dicts and answers "which services are erroring, and what are the most common errors?" — the sort of thing a DevOps agent asks a hundred times a day.

Think of it like cooking a dish after learning the knife skills separately. You already know how to filter (a comprehension), how to group and count (defaultdict), how to rank (sorted with a key), how to tally the top few (Counter.most_common), and how to format output cleanly (f-strings). The value of a worked example is seeing the order they go in and how each one's output becomes the next one's input — the flow, not the ingredients.

Watch for the shape of the pipeline as you read, because it's a pattern you'll reuse far beyond logs: filter down to what matters → group and count → rank → report. Almost every "summarize this data" task in the course follows that same four-step spine, whether it's logs, alerts, evaluation results, or retrieval hits. The mistake to avoid is trying to do everything in one tangled loop; notice instead how the code keeps each step small, named, and separate, so you could read, test, or change any one of them without disturbing the others. That separation is what makes the difference between a clever script and code a teammate can maintain.

log_analyzer.pyfrom collections import Counter, defaultdict

LOGS = [
    {"svc": "checkout-api", "level": "ERROR", "msg": "auth failed"},
    {"svc": "checkout-api", "level": "ERROR", "msg": "startup probe failed"},
    {"svc": "web-frontend", "level": "ERROR", "msg": "upstream 503"},
    {"svc": "web-frontend", "level": "INFO",  "msg": "served /"},
]

def summarize(logs):
    errors = [l for l in logs if l["level"] == "ERROR"]        # filter
    by_svc = defaultdict(int)                                     # group-count
    for e in errors:
        by_svc[e["svc"]] += 1
    ranked = sorted(by_svc.items(), key=lambda kv: -kv[1])       # worst first
    return errors, ranked

def main():
    errors, ranked = summarize(LOGS)
    print(f"{len(errors)} errors across {len(ranked)} services\n")
    for svc, n in ranked:
        print(f"  {svc:16} {n} error(s)")
    print("\ntop error messages:")
    for msg, n in Counter(e["msg"] for e in errors).most_common(3):
        print(f"  {n}x  {msg}")

if __name__ == "__main__":
    main()

3 errors across 2 services

  checkout-api     2 error(s)
  web-frontend     1 error(s)

top error messages:
  1x  auth failed
  1x  startup probe failed
  1x  upstream 503

Exercises advanced

pods = [
    {"id": "x1", "text": "demo one", "name": "api-7f9c", "status": "Running"},
    {"id": "x2", "text": "demo two", "name": "worker-2d", "status": "CrashLoopBackOff"},
]

broken = [p["name"] for p in pods if p["status"] != "Running"]

import json
state = json.load(open("state.json"))
print(state["pods"][0]["logs"][-1])

🎯 Interview practice interview

The interview questions this topic gets asked — worked, with code. For the full pattern catalog see A9 · Big Tech AI-engineering patterns.

pythonfrom collections import defaultdict
def group_anagrams(words):
    groups = defaultdict(list)
    for w in words:
        groups["".join(sorted(w))].append(w)   # key = canonical form
    return list(groups.values())

pythonfrom collections import Counter
def first_uniq(s):
    freq = Counter(s)
    for i, c in enumerate(s):
        if freq[c] == 1:
            return i
    return -1

LOGS = [
    {"svc": "checkout-api", "level": "ERROR", "msg": "auth failed"},
    {"svc": "web-frontend", "level": "INFO",  "msg": "served /"},
    {"svc": "web-frontend", "level": "ERROR", "msg": "upstream 503"},
]
errors = [l for l in LOGS if l["level"] == "ERROR"]
print(len(errors), "errors")   # 2 errors

from collections import defaultdict

errors = [
    {"svc": "checkout-api", "msg": "auth failed"},
    {"svc": "checkout-api", "msg": "probe failed"},
    {"svc": "web-frontend", "msg": "upstream 503"},
]
by_svc = defaultdict(int)
for e in errors:
    by_svc[e["svc"]] += 1
ranked = sorted(by_svc.items(), key=lambda kv: -kv[1])
for svc, n in ranked:
    print(f"{svc:16} {n} error(s)")

from collections import Counter

errors = [{"msg": m} for m in
          ["auth failed", "upstream 503", "auth failed", "timeout", "auth failed"]]
top = Counter(e["msg"] for e in errors).most_common(3)
for msg, n in top:
    print(f"{n}x {msg}")   # 3x auth failed, then the rest

import re

LINE = re.compile(r"^\S+ (?P<level>\w+) (?P<svc>[\w-]+) \| (?P<msg>.+)$")

raw = [
    "2026-09-04 ERROR checkout-api | auth failed",
    "garbage line that does not match",
    "2026-09-04 INFO web-frontend | served /",
]
records = []
for line in raw:
    m = LINE.match(line)
    if m:
        records.append(m.groupdict())
print(records)

import json
from collections import Counter

def summarize_json(text):
    try:
        logs = json.loads(text)
    except json.JSONDecodeError as e:
        return json.dumps({"error": f"bad json: {e.msg}"})
    counts = Counter(l["level"] for l in logs)
    return json.dumps({"by_level": dict(counts)}, sort_keys=True)

good = '[{"level":"ERROR"},{"level":"INFO"},{"level":"ERROR"}]'
print(summarize_json(good))       # {"by_level": {"ERROR": 2, "INFO": 1}}
print(summarize_json('{not json'))  # {"error": "bad json: ..."}

from collections import Counter, defaultdict

def summarize(logs):
    errors = [l for l in logs if l["level"] == "ERROR"]
    by_svc = defaultdict(int)
    for e in errors:
        by_svc[e["svc"]] += 1
    ranked = sorted(by_svc.items(), key=lambda kv: -kv[1])
    top = Counter(e["msg"] for e in errors).most_common(3)
    return {"error_count": len(errors), "by_service": ranked, "top_messages": top}

LOGS = [
    {"svc": "checkout-api", "level": "ERROR", "msg": "auth failed"},
    {"svc": "checkout-api", "level": "ERROR", "msg": "probe failed"},
    {"svc": "web-frontend", "level": "ERROR", "msg": "upstream 503"},
    {"svc": "web-frontend", "level": "INFO",  "msg": "served /"},
]
r = summarize(LOGS)
assert r["error_count"] == 3 and r["by_service"][0] == ("checkout-api", 2)
print(r)

Knowledge check check yourself