Four days of one-shape answers — an int, a str, a list of strs. Today you return three different things at once. What shape collects multiple fields under named keys?
A dict. Each field gets a named key instead of a positional slot.
Exactly. One search() call gives you all the raw material — count, URLs, titles. You build the summary in the function body and hand back a dict:
results = search("python web frameworks", count=5)
summary = {
"count": len(results),
"top_url": results[0]["url"],
"titles": [r["title"] for r in results],
}One API call, three computed fields. No second search — that would be a wasted round trip.
So I can reuse results three times in the same function. One network call, three derived values.
Efficiency matters. Every search() is a real HTTP request. If you can compute three outputs from one call, do it. The full pattern:
def search_summary_dict(query: str, count: int) -> dict:
results = search(query, count=count)
return {
"count": len(results),
"top_url": results[0]["url"],
"titles": [r["title"] for r in results],
}Why a dict instead of returning three separate values — like return count, top_url, titles?
Positional returns force the caller to remember the order. Named keys document themselves: the caller sees summary["top_url"] and knows exactly what they're reading. When Week 2 starts layering agents onto this data, the dict shape is also what Pydantic models and agent tools expect as input.
And this is the last Week 1 function — all of Friday's work is reusing the search patterns from Monday through Thursday.
Exactly. Count, first snippet, URL list, formatted lines, summary dict. Five small functions, one primitive. Week 2 wires an agent onto this same shape — every function there starts with results = search(...) and reasons over what you've already learned to read.
TL;DR: one search() call feeds multiple computed fields of a returned dict.
len(results) — countresults[0]["url"] — top URL[r["title"] for r in results] — all titles| Field | Derivation |
|---|---|
| count | len(results) |
| top_url | results[0]["url"] |
| titles | comprehension over results |
Returning a dict beats positional values — the caller never has to remember the order, and downstream agents can read named keys directly.
Four days of one-shape answers — an int, a str, a list of strs. Today you return three different things at once. What shape collects multiple fields under named keys?
A dict. Each field gets a named key instead of a positional slot.
Exactly. One search() call gives you all the raw material — count, URLs, titles. You build the summary in the function body and hand back a dict:
results = search("python web frameworks", count=5)
summary = {
"count": len(results),
"top_url": results[0]["url"],
"titles": [r["title"] for r in results],
}One API call, three computed fields. No second search — that would be a wasted round trip.
So I can reuse results three times in the same function. One network call, three derived values.
Efficiency matters. Every search() is a real HTTP request. If you can compute three outputs from one call, do it. The full pattern:
def search_summary_dict(query: str, count: int) -> dict:
results = search(query, count=count)
return {
"count": len(results),
"top_url": results[0]["url"],
"titles": [r["title"] for r in results],
}Why a dict instead of returning three separate values — like return count, top_url, titles?
Positional returns force the caller to remember the order. Named keys document themselves: the caller sees summary["top_url"] and knows exactly what they're reading. When Week 2 starts layering agents onto this data, the dict shape is also what Pydantic models and agent tools expect as input.
And this is the last Week 1 function — all of Friday's work is reusing the search patterns from Monday through Thursday.
Exactly. Count, first snippet, URL list, formatted lines, summary dict. Five small functions, one primitive. Week 2 wires an agent onto this same shape — every function there starts with results = search(...) and reasons over what you've already learned to read.
TL;DR: one search() call feeds multiple computed fields of a returned dict.
len(results) — countresults[0]["url"] — top URL[r["title"] for r in results] — all titles| Field | Derivation |
|---|---|
| count | len(results) |
| top_url | results[0]["url"] |
| titles | comprehension over results |
Returning a dict beats positional values — the caller never has to remember the order, and downstream agents can read named keys directly.
Create a free account to get started. Paid plans unlock all tracks.