Week 11: dictionaries and nested data

You have been using dictionaries since Week 8, but only one way: look a key up, add one to its value. This week you get the rest of the toolkit. Dictionary methods like get() and items() let you look things up without crashing on a missing key and loop over keys and values together. Comprehensions build a whole list, set, or dictionary in one line, so a five-line accumulator loop becomes one readable expression. Next week, the data gets nested (lists of tuples, dictionaries of lists, whole files of dictionaries), and you'll reach into it with loops inside loops.

This week starts your fourth programming assignment (PA4), and like PA3 it runs for two weeks, in four parts plus a test file. Parts A and B use this week's dictionaries and comprehensions. Parts C and D use next week's nested data: a loop inside a loop, and a JSON file full of dictionaries. Part E is the test file: as in PA2, you write the tests and submit them along with your code.

Save your PA in the Week11 folder inside ~/CS149, keep working on it there next week, and commit and push your work whenever you finish a part. PA4 has one assignment on Gradescope, and you can submit as many times as you like, so check your work as you go.

Submit early to Gradescope

If you don't submit to Gradescope and get a nonzero score, you will receive a reflection grade of no higher than 15/30 points. PA4 is one Gradescope assignment that runs for both weeks, and the same rule applies each week. Submit this week once Parts A and B work and test_count_patches and test_rule_breaks have their asserts, then submit again next week when the whole PA is finished. Parts C and D will show as not done yet, and so will Part E: Gradescope scores your tests only once all four test functions are written.

Parts C and D are next week's

They need nested loops and JSON files, which start in next week's first class. Finish A and B this week, and leave C and D alone until then. Their docstrings are already in the file, so you can read ahead if you are curious.

SoDuckYou 🐥

A pond is split into patches of different colors, and you have a flock of very particular ducks. Every row, every column, and every patch needs exactly one duck, and no two ducks may touch, not even corner to corner. Ducks need their personal space. Your code is the referee: after every move, it checks the pond and tells the player which rules are broken, right up until the moment they solve it.

Start SoDuckYou → or play it first

The parts

SoDuckYou is one file with four functions, one per part, plus a JSON data file the program reads. The main block that runs the finished program is written for you. You also fill in a test file, test_soduckyou.py, with a test for each function (Part E), and you submit it with your code.

Part	Week	What you write	What you practice
A	11	`count_patches`	a dictionary comprehension that starts every count at 0, then a loop that counts
B	11	`rule_breaks`	counting with `get()`, then looping over `items()` to report what's wrong, in order
C	12	`touching`	a loop inside a loop that finds every pair that matches a rule
D	12	`load_levels`	reading a JSON file of dictionaries, and keeping the parts you need
E	11–12	`test_soduckyou.py`	tests that pass on correct code and catch buggy code

Work one part at a time

Each part builds on the one before: Part B calls your Part A, and the main block needs all four. Get a part working and submitted before you start the next, and write its test as you go, including the edge cases its docstring mentions.

When you're done

Commit and push your Week11 folder after each part:

git add -A
git commit -m "Finish PA4 Part A"
git push

When Part A works, look at your dictionary comprehension and write it out again as a regular for loop with an accumulator. Then go the other way with one of your loops from PA3. If you can switch between the two in both directions, you really understand what a comprehension does, and you can read one on paper without running it.