Three separate variables — category, amount, date — are fine for one expense. But what happens when you have twenty, and each one needs to travel through three different functions?
They'd get tangled. I'd end up passing three arguments to every function, in the same order each time, hoping I didn't swap any.
That's exactly the pain a dictionary removes. A dict bundles related fields under named keys — one object, easy to pass around, labels baked in:
{"category": "Food", "amount": 12.5, "date": "2024-04-01"}
So the dict is the "shape" of one transaction — every expense in the whole tracker will look like this?
Yes. Once you commit to that shape, the rest of the track builds on it. Every list of expenses is a list of these dicts. Every function that reads an expense reaches in with t["category"] or t["amount"]:
def build_transaction(category, amount, date):
return {"category": category, "amount": amount, "date": date}
The keys are strings in quotes but the values are variables. Is that always how dict literals look?
Yes. "category" is a string key — in quotes. category on the right is the variable holding the value. Keys are usually strings in a data shape like this; values can be any type.
So one function call turns three loose pieces into one labeled object. That's cleaner than I expected.
Cleaner and safer. You never swap the order of arguments by accident again — the keys guard you.
TL;DR: a dict bundles named fields into one object — the shape of data for the rest of the track.
t["category"] reads one field| Key | Type | Example |
|---|---|---|
category | str | "Food" |
amount | float | 12.5 |
date | str | "2024-04-01" |
One shape everywhere means one set of reads everywhere. t["amount"] always means the same thing.
Write `build_transaction(category, amount, date)` that returns a dict with keys `"category"`, `"amount"`, `"date"`. Example: `build_transaction("Food", 12.5, "2024-04-01")` returns `{"category": "Food", "amount": 12.5, "date": "2024-04-01"}`.
Tap each step for scaffolded hints.
No blank-editor panic.
Three separate variables — category, amount, date — are fine for one expense. But what happens when you have twenty, and each one needs to travel through three different functions?
They'd get tangled. I'd end up passing three arguments to every function, in the same order each time, hoping I didn't swap any.
That's exactly the pain a dictionary removes. A dict bundles related fields under named keys — one object, easy to pass around, labels baked in:
{"category": "Food", "amount": 12.5, "date": "2024-04-01"}So the dict is the "shape" of one transaction — every expense in the whole tracker will look like this?
Yes. Once you commit to that shape, the rest of the track builds on it. Every list of expenses is a list of these dicts. Every function that reads an expense reaches in with t["category"] or t["amount"]:
def build_transaction(category, amount, date):
return {"category": category, "amount": amount, "date": date}The keys are strings in quotes but the values are variables. Is that always how dict literals look?
Yes. "category" is a string key — in quotes. category on the right is the variable holding the value. Keys are usually strings in a data shape like this; values can be any type.
So one function call turns three loose pieces into one labeled object. That's cleaner than I expected.
Cleaner and safer. You never swap the order of arguments by accident again — the keys guard you.
TL;DR: a dict bundles named fields into one object — the shape of data for the rest of the track.
t["category"] reads one field| Key | Type | Example |
|---|---|---|
category | str | "Food" |
amount | float | 12.5 |
date | str | "2024-04-01" |
One shape everywhere means one set of reads everywhere. t["amount"] always means the same thing.