Lists & Tuples

You write a list with square brackets and commas, holding items of any type - usually all the same type, because they mean the same kind of thing:

rooms = ["living", "kitchen", "bath", "bed1", "bed2"]
areas = [24.0, 12.5, 4.5, 15.0, 12.0]

Each item sits at a numbered position, called its index, and here is the rule that catches everyone at first: indexing starts at 0. So rooms[0] is "living", rooms[1] is "kitchen", and rooms[4] is the fifth and last item, "bed2". Asking for rooms[5] raises an IndexError because there is no sixth item. Python also lets you count from the end with negative indices: rooms[-1] is the last item, rooms[-2] the second-to-last - handy when you do not know or care how long the list is.

print(rooms[0])    # living
print(rooms[-1])   # bed2
print(len(rooms))  # 5  - how many items

The built-in len() tells you how many items a list holds, which you will use constantly. Zero-based indexing feels arbitrary until you realise it pairs perfectly with the range() and loop behaviour from the last lesson - the valid indices of a list of length 5 are exactly 0, 1, 2, 3, 4, which is precisely what range(len(rooms)) gives you.

One mental model helps all of this stick: picture a list as a row of numbered pigeon-holes. The number on each hole is its index, counting from zero at the left; the thing inside is the item. Indexing hands you what is in one hole; slicing hands you a fresh row copied from a range of holes; len tells you how many holes there are. Every list operation is some variation on reaching into, copying from, or adding holes to that row - and once the picture is fixed, the off-by-one worries fade. It is a picture worth keeping, because the very same indexing carries straight over to strings, to rows of tabular data, and later to arrays of points and pixels.

Where an index gives you one item, a slice gives you a range of them, using the colon: list[start:stop]. As with range(), the slice includes the start position but stops before the stop position - the same half-open rule, which is why it looks off by one until it becomes second nature:

rooms = ["living", "kitchen", "bath", "bed1", "bed2"]
print(rooms[1:3])   # ['kitchen', 'bath']  - positions 1 and 2
print(rooms[:2])    # ['living', 'kitchen'] - from the start
print(rooms[3:])    # ['bed1', 'bed2']      - to the end
print(rooms[-2:])   # ['bed1', 'bed2']      - last two

Leaving out the start means 'from the beginning'; leaving out the stop means 'to the end'. A slice always hands back a new list, leaving the original untouched - so first_two = rooms[:2] gives you a fresh two-item list you can work with independently. This same slicing syntax works on strings too (a string is a sequence of characters), which is why name[:3] gives the first three letters. Slicing is how you grab the first N drawings, the last few rooms, or every item except the header row of some data - a small piece of syntax you will reach for far more than you expect.

Lists are mutable - they can change after you make them, which is exactly what you want when you are building up a result inside a loop. The most common move is .append(), which adds one item to the end:

large_rooms = []                 # start empty
for room, area in zip(rooms, areas):
    if area >= 15:
        large_rooms.append(room)
print(large_rooms)   # ['living', 'bed1']

That pattern - start an empty list, loop, and .append() the items that pass a test - is one you will write hundreds of times; it is how you filter and collect. Beyond append, a list carries a toolkit of methods, functions attached to it that you call with a dot: .sort() orders it in place, .reverse() flips it, .insert(i, x) puts an item at a position, .remove(x) deletes the first matching item, .pop() removes and returns the last, and .count(x) tallies occurrences. You can also change an item directly by its index - rooms[0] = "lounge" - and join two lists with +. A word of care that follows from mutability: writing b = a for two lists does not copy the list, it gives the same list a second name, so changing b also changes a. When you truly want an independent copy, use a.copy() or a[:]. This shared-name behaviour surprises nearly every beginner once, and knowing it exists saves a baffling afternoon.

A tuple is a list that cannot change. You write it with parentheses instead of square brackets, and once made, you cannot append to it or reassign its items - it is immutable:

point = (12.0, 9.0)     # an (x, y) coordinate
print(point[0])         # 12.0  - index it just like a list
# point[0] = 5.0        # ERROR - tuples cannot change

Why would you want a collection you cannot edit? Because immutability is a feature when the grouping is fixed: an (x, y) or (x, y, z) point, an (R, G, B) colour, a (width, height) pair. The tuple signals 'these belong together and should not be altered', and it can be used as a dictionary key (next lesson) where a list cannot. Use a list when the collection grows or changes; use a tuple for a fixed little record.

Finally, a taste of one of Python's most-loved features, the list comprehension - a compact way to build a new list from an existing one, folding a loop into a single readable line:

areas = [24.0, 12.5, 4.5, 15.0]
sqft = [a * 10.764 for a in areas]              # convert every area
big = [a for a in areas if a >= 12]             # keep only the big ones
print(sqft)   # [258.3, 134.5, 48.4, 161.5]
print(big)    # [24.0, 12.5, 15.0]

Read [a * 10.764 for a in areas] as 'a times 10.764, for each a in areas'. It does exactly what an empty-list-plus-append loop does, in one line, and the optional if filters as it goes. Do not force everything into a comprehension - a plain loop is clearer when the body is long - but for the very common 'transform or filter a list into a new list', it is the idiomatic Python move, and you will see it everywhere in the modules ahead.

Two more moves make lists genuinely comfortable. The first is the list of lists - a list whose items are themselves lists, which is how a table lives in plain Python before you reach a library like pandas. Each inner list is a row:

schedule = [
    ["living", 24.0],
    ["kitchen", 12.5],
    ["bath", 4.5],
]
print(schedule[0])      # ['living', 24.0]  - the first row
print(schedule[0][1])   # 24.0             - row 0, column 1

You reach a cell with two indices - schedule[0][1] means 'first row, second column'. This nesting is exactly the shape of a spreadsheet, and looping over it row by row is how you would total a column or reformat a schedule by hand before a library does it for you.

The second move is unpacking, which makes looping over such rows a pleasure. Rather than reaching in by index, you name the parts directly in the for line:

for name, area in schedule:
    print(f"{name}: {area} sqm")

Each inner list (or tuple) is unpacked into name and area in one step - cleaner than row[0] and row[1], and it reads like the data it describes. This is the same unpacking that let enumerate and zip hand you two variables at once in the last lesson, and the same idea behind x, y = point for a coordinate pair.

Finally, a handful of built-in functions turn a list into an answer without a loop at all: sum(areas) totals it, min(areas) and max(areas) find the extremes, len(areas) counts it, and sorted(areas) returns a new sorted list - leaving the original untouched, unlike .sort(), which reorders in place and returns None. The in keyword tests membership (if "kitchen" in rooms:) and .index(x) finds an item's position. Knowing these saves you from re-writing loops for jobs Python already does: when you catch yourself looping just to add numbers up or find the largest, reach for the built-in instead. Between indexing, slicing, appending, nesting, unpacking and this toolkit of built-ins, the list will carry more of your scripting than any other structure - which is exactly why it repays learning its habits properly now, on data you understand, before the later modules pile real complexity on top.

It is also worth a word on when not to reach for a list. A list is the right home for an ordered sequence you process or index, but if you find yourself constantly searching a list for a particular item by name - scanning every entry to find 'the kitchen' - that searching is a sign the data really wants a dictionary, which the next lesson introduces. And if you are only ever asking 'is this value present?' or 'what are the distinct values?', a set will serve you better. The list is the default and the workhorse, but part of using it well is recognising the two moments its cousins do the job more cleanly: lookup by name, and questions of uniqueness.