Dictionaries & Sets

A dictionary stores key -> value pairs inside curly braces. The key is what you look something up by; the value is what you get back. For design data, the key is usually a name and the value is a number, a string, or even another collection:

areas = {
    "living": 24.0,
    "kitchen": 12.5,
    "bath": 4.5,
    "bed1": 15.0,
}
print(areas["kitchen"])   # 12.5

You fetch a value by putting its key in square brackets - areas["kitchen"] - and it comes back immediately, no matter how many entries the dictionary holds. That is the dictionary's superpower: lookup by key is fast and direct, where finding something in a list would mean scanning through it. The keys are unique - a dictionary cannot hold two "kitchen" entries, and assigning to an existing key overwrites its value. Asking for a key that does not exist, like areas["garage"], raises a KeyError; when you are unsure a key is present, use the .get() method, which returns None (or a default you supply) instead of crashing:

print(areas.get("garage"))        # None - no error
print(areas.get("garage", 0.0))   # 0.0 - your default

Dictionaries are mutable, so you add or update an entry just by assigning to a key - if the key exists it is updated, if not it is created:

areas["study"] = 9.0        # add a new pair
areas["bath"] = 5.0         # update an existing one
del areas["bed1"]           # remove a pair
print(len(areas))           # how many pairs now

The move you will use most is looping over a dictionary. Iterating it directly gives you the keys, but usually you want both key and value together, which is what .items() provides:

total = 0
for room, area in areas.items():
    print(f"{room}: {area} sqm")
    total = total + area
print(f"Total: {total} sqm")

That for key, value in d.items(): pattern is the bread and butter of dictionary work - it walks every pair so you can report, total or transform them. There are two companions: .keys() gives just the names (for room in areas.keys():) and .values() gives just the numbers (sum(areas.values()) totals every area in one line). And the in keyword tests membership against the keys - if "kitchen" in areas: is a clean, crash-free way to check before you look up. Values themselves can be richer than single numbers: a room could map to a list of its finishes, or to another dictionary of its properties, which is how real project data - nested and structured - gets modelled in code. This is also, not coincidentally, the shape of the JSON files you will read in Module 3.

The two parallel lists from the last lesson - rooms and areas kept in step - were a warning sign. Whenever you find yourself maintaining two lists that must stay aligned by position, a dictionary is almost always the better structure, because it binds the name and the value into one unit that cannot drift out of sync:

# fragile - two lists that must stay aligned
rooms = ["living", "kitchen", "bath"]
areas = [24.0, 12.5, 4.5]

# robust - one dict, name bound to value
areas_by_room = {"living": 24.0, "kitchen": 12.5, "bath": 4.5}

Choose a list when order is the point and you access by position or just process every item in sequence - a run of points, a sequence of drawings, a queue of files. Choose a dictionary when you look things up by a meaningful name, when each item has a natural identifier, or when you are counting or grouping. Counting is a classic dict job: to tally how many rooms use each finish, you loop once and use the finish name as a key, adding to its running count. Grouping is another - map each department name to a list of its rooms. As a rule of thumb: if the sentence describing your data contains the word 'per' or 'by' - area per room, cost by trade, count by material - you almost certainly want a dictionary.

It is worth saying plainly that these choices are not academic. Picking the wrong collection is one of the most common reasons a beginner's script becomes tangled and slow: scanning a list in a loop to find something when a dict would look it up directly; keeping three parallel lists in step by hand when one dict of records would hold them together; letting duplicates pile up in a list when a set would answer the real question in a line. The collection you choose shapes how clear and how fast everything downstream is, so it is worth a moment's thought at the start rather than a painful rewrite later.

The last core collection is the set - an unordered collection that automatically holds only unique items. Make one from a list and every duplicate silently vanishes:

materials = ["oak", "teak", "oak", "glass", "teak", "oak"]
distinct = set(materials)
print(distinct)        # {'oak', 'teak', 'glass'}  - order not guaranteed
print(len(distinct))   # 3  - how many different finishes

This answers a question you ask on every project: what distinct things are here? How many different finishes across the scheme, which unique room types exist, what set of drawing numbers appears in a folder. A set does it in one line. Sets are also built for membership tests - checking whether an item is present with in is very fast, faster than scanning a list, which matters when you are checking thousands of items against a known collection. And they support the operations you learned in school as Venn diagrams: a & b gives what is in both (the intersection - say, materials used on both floors), a | b gives everything in either (the union), and a - b gives what is in the first but not the second (the difference - rooms specified but not yet drawn). The trade-off is that a set has no order and no indexing - you cannot ask for distinct[0] - and it cannot contain duplicates by definition. Reach for a set specifically when uniqueness or fast membership is the point; reach for a list when order and repeats matter; reach for a dict when you look up values by a key. With those three in hand, you can model almost any design data a script will meet.

Two dictionary patterns come up so constantly in design work that they deserve to be learned as set pieces: counting and grouping. Both use a key to accumulate, and both are how you turn a flat list into a summary.

Counting answers 'how many of each?'. Walk a list once and use each item as a key whose value is a running tally. The .get(key, 0) method makes it clean by supplying a starting count of zero for any key not yet seen:

materials = ["oak", "teak", "oak", "glass", "teak", "oak"]
counts = {}
for m in materials:
    counts[m] = counts.get(m, 0) + 1
print(counts)   # {'oak': 3, 'teak': 2, 'glass': 1}

That is a materials take-off in five lines - how many times each finish appears across a scheme - and the identical shape counts rooms per type, drawings per discipline, or fittings per supplier.

Grouping answers 'which items belong to each category?'. Here each value is a list, and you append to it. Use .setdefault(key, []) to start an empty list the first time a key appears, then add to it:

rooms = [("living", "public"), ("kitchen", "service"), ("bath", "service")]
by_zone = {}
for name, zone in rooms:
    by_zone.setdefault(zone, []).append(name)
print(by_zone)   # {'public': ['living'], 'service': ['kitchen', 'bath']}

That collects rooms by zone in a single pass - the raw move behind a departmental area schedule or a finishes matrix grouped by room type. Notice that the value is now a list living inside a dict, which is the everyday face of nesting: dicts holding lists, lists holding dicts, dicts holding dicts. A single room might be a dict of its own - {"name": "kitchen", "area": 12.5, "finishes": ["tile", "laminate"]} - and a whole project a list of such dicts. That nested shape is not an advanced curiosity; it is precisely how JSON stores data and how you will receive information from files, spreadsheets and design software in the modules ahead. Master counting, grouping and a comfort with nesting, and you have the core of practical data handling - everything Module 3 and the pandas work in Module 4 build on is a richer version of these same few moves over these same few collections.

Step back and the whole module fits in a sentence: conditionals let a script decide, loops let it repeat, and lists, dictionaries and sets let it hold data in the shape that matches the question being asked. Almost everything you will build from here - reading files, cleaning a spreadsheet, generating a grid of geometry, extracting data from a model - is these few pieces recombined over larger and messier data. There is no secret extra layer waiting in the advanced modules; there is only more practice fitting these same moves to real problems. If the four lessons of this module feel solid, you are genuinely ready for the rest of the course, because the rest of the course is this module applied.