Organizing and Traversing Collections Overview
1. One game state needs four collection jobs
Imagine a small exploration game. Its current state contains an ordered route, a fixed map coordinate, a named player record, and a group of unique skills:
All four values hold several other values, but they do not promise the same behavior:
- a list keeps a deliberate order and can grow, shrink, or change;
- a tuple keeps a fixed sequence of positions;
- a dictionary connects unique keys with values; and
- a set keeps unique members for fast membership and group comparisons.
The question is not “Which collection is best?” There is no best collection in isolation. The useful question is “Which relationships must this part of the program preserve?”
“Keep every checkpoint in visit order, including repeats” points toward a list. “Find the player’s energy by the key energy” points toward a dictionary. A precise statement of the job usually makes the Python type easier to choose.
2. Choose from the question the program asks
Use these decision axes before reaching for familiar syntax:
| Program requirement | Collection to consider | Important trade-off |
|---|---|---|
| Preserve position and permit edits | list |
Finding an arbitrary value usually scans the list. |
| Preserve a small fixed positional record | tuple |
Its positions cannot be replaced, added, or removed. |
| Look up a value by a stable unique key | dict |
Keys must be hashable and communicate real identity. |
| Remove duplicates or compare membership groups | set |
It offers no numeric position or display-order promise. |
| Keep an immutable set value | frozenset |
It cannot be changed after construction. |
Ask six questions about new data:
- Does order carry meaning?
- Are duplicates meaningful or noise?
- Will the program ask by position, by key, or only by membership?
- Must the collection change in place?
- Do several fields belong to one record?
- Is the data nested, and can you describe the type at every level?
One artifact can legitimately use several answers. For example, a list of dictionaries preserves record order while each dictionary gives fields names.
3. Your path through this unit
| Lesson | Capability you will build | Main lab artifact |
|---|---|---|
| 1 | Lists: Keeping Values in Order — index, slice, change, search, add, remove, copy, and explain method returns. | Adventure backpack |
| 2 | Tuples and Unpacking Fixed Records — recognize tuple syntax and unpack fixed or starred shapes. | Treasure-map clues |
| 3 | Dictionaries: Finding Values by Key — distinguish missing keys, update mappings, use views, and build records, counters, and groups. | Creature codex |
| 4 | Sets: Uniqueness and Group Comparisons — deduplicate, compare groups, and use immutable frozenset values. |
Expedition skills |
| 5 | Visiting Items in a Collection — trace what lists, dictionaries, ranges, enumerate(), and zip() supply. |
Route manifest |
| 6 | Sorting Collections Without Losing Meaning — rank values and complete records with an explicit stable policy. | Tournament leaderboard |
| 7 | Building and Reading Nested Data — navigate one level at a time and refactor shapes for new questions. | Game-world archive |
The Unit Challenge combines those capabilities in a signal-vault puzzle. You will decode an ordered archive without mutating its evidence.
4. What you already know from Unit 2
This unit builds on scalar values rather than replacing them. You will reuse:
- integers for positions, counts, and scores;
- strings for IDs, labels, and the final decoded message;
Nonefor a deliberately missing value;- comparisons and Boolean values for assertions and membership facts;
- string indexing, slicing, and
"".join(...); and - errors as evidence about a value’s type and the attempted operation.
Collections answer a different layer of the design question. 80 can represent one energy value; {"energy": 80} preserves the relationship between the label and that value; a list of such dictionaries preserves several player records in an order.
5. Simple traversal now, full control flow next
You need a small amount of for-loop syntax to observe what collections supply:
Read this as “for each value supplied by signals, bind that value to signal and run the indented line.” The loop visits every list item in order.
Unit 3 uses simple traversal to explain collection behavior. Unit 4 develops conditional rules, accumulators, filtering, break, continue, nested loops, while loops, and comprehensions. When a Unit 3 lab supplies a small if statement, the collection decision—not the branching syntax—is the work being assessed.
6. Set up a collection laboratory
State changes are easier to understand when one notebook cell has one purpose. Use a five-part layout:
# 1. Untouched source evidence
source_route = ["dock", "garden", "vault"]
# 2. A deliberate working copy
working_route = source_route.copy()
# 3. One operation under investigation
removed_stop = working_route.pop(1)
# 4. Observable facts
print(removed_stop)
print(source_route)
print(working_route)
# 5. Checks that state the promises
assert removed_stop == "garden"
assert source_route == ["dock", "garden", "vault"]
assert working_route == ["dock", "vault"]Do not keep rerunning only the final cell after earlier state has changed. Use Restart and run all periodically so the notebook proves that its result can be reproduced from a clean state.
Two collection values can display with similar punctuation and still offer very different operations. Check type(value).__name__, inspect the construction syntax, and state the required relationship instead of guessing from appearance.
7. Choose a realistic pace
Unit 3 is planned for approximately 23–34 hours, including reading, running examples, completing checkpoints, modifying code, doing the seven labs, and solving the challenge. That range is guidance, not a deadline.
A sustainable rhythm is:
- complete one numbered section and its modification;
- stop after a checkpoint and explain one answer aloud;
- return for the next group of operations;
- do the final lab without opening its support first; and
- record one error, its actual cause, and the evidence that confirmed the repair.
If the lab feels like copying rather than deciding, close the solution, change the input data, and rebuild the checks for the new case.
8. Before you continue
Run this readiness task from a clean cell:
route = ["dock", "garden", "observatory"]
position = (12, 7)
pilot = {"name": "Nova", "energy": 80}
skills = {"mapping", "repair", "mapping"}
assert route[1] == "garden"
assert position[0] == 12
assert pilot["energy"] == 80
assert skills == {"mapping", "repair"}
print(f"{pilot['name']} starts at {route[0]} with {len(skills)} unique skills.")Then make four changes:
- add
"vault"to the end ofroute; - replace the energy value with
95by using its dictionary key; - add one new unique skill; and
- prove with assertions that
positionand the original three route entries still have the expected values.
You are ready for Lesson 1 when you can point to the exact collection each line changes and explain why the other three values remain unchanged.
Key points
- Choose a collection from the relationships and operations the program needs.
- Lists preserve editable order, tuples preserve fixed positions, dictionaries connect keys to values, and sets preserve unique membership.
- Real programs combine collection types; nested shape should be deliberate.
- Keep source evidence, working state, observations, and assertions separate.
- Unit 3 owns collection behavior and simple traversal; Unit 4 develops complete control-flow design.