Overview

At the end of Part 3, you could divide a program into functions with clear responsibilities. You could explain which objects a function receives, what it returns or changes, and how to check its behavior.

Those questions remain useful. This part adds another:

How should the information itself be organized?

Consider the example from the Part 3 recap:

student = ["Ada", 42, "Computer Science"]

The list stores the information, but the program has to remember what each position means. Does student[1] mean points, age, or something else? A comment might help, but the representation itself does not say.

A dictionary gives the fields names:

student = {
    "name": "Ada",
    "points": 42,
    "programme": "Computer Science"
}

Now the program can ask for student["points"]. The new notation makes a relationship visible: the value 42 belongs to the field named "points".

This does not mean that dictionaries replace lists. A roll of five dice still fits naturally in a list. The positions in Word Clues still connect a guessed character with its clue. Choosing a representation means asking what relationships matter, not selecting whichever structure was taught most recently.

You will combine familiar lists and functions with dictionaries, work with records and grids, and apply the loop patterns from Part 2 to structured information. The names-and-objects model from Part 3 will help explain what happens when several structures refer to the same record.

After working through this part, you should be able to choose a suitable representation for structured information, process it with functions, and test both the returned results and any changes to shared data.

The structure of this part is as follows:

• Dictionaries and Named Information introduces keys, values, updates, and missing information.
• Processing and Building Dictionaries uses loops to inspect dictionaries and build counts.
• Collections of Records combines lists and dictionaries, then examines searching, filtering, and copying records.
• Nested Data and Grids represents information inside other information, including pixel images and two-dimensional lists.
• Grouping and Summarizing Data compares repeated scanning with one-pass grouping and introduces sorting with a named key function.
• Choosing and Checking a Representation compares useful designs against requirements, including an AI-proposed contact index.
• Data and Games applies grids, shared records, snapshots, and grouped reports in Campus Courier.
• Recap and Feedback combines the ideas in an equipment-catalogue exercise.

Recommended Order of Work

Work through the 18 programming exercises and shorter tasks for tracing, reviewing, arranging, and explaining code as they appear. Campus Courier combines the data structures in a game; the equipment catalogue brings together record selection, copying, and grouped reports.

At the end of Chapter 3, Processing and Building Dictionaries, complete the LEIA dictionary activity and its survey before moving on to collections of records.

Start each function by identifying what its input contains and what it should return or change. Then test ordinary and boundary cases as you did in Part 3, including empty input where the function accepts it.

When nested data becomes difficult to follow, write down what each expression refers to. For example, a list may contain records, and a field inside one record may contain another list. Follow one step at a time rather than trying to hold the whole structure in your head.

After Chapter 5, check that you can follow access through a nested structure and explain which objects a copy leaves shared. The later exercises use those ideas when grouping records and recording deliveries.

Pay particular attention to a distinction that tests do not reveal unless you ask about it:

Does the function return new data, or another way to reach existing data?

The answer affects what happens when the caller changes the result.