Welcome back. You finished Track 1 — the Monday report runs, Diane is happy, and now the warehouse team has a pile of spreadsheets they want you to fix. How are you feeling about it?
Honestly? Pretty confident. I know how to loop, write functions, read CSVs. But the warehouse data is messier than the sales data. Product specs have like six fields and I keep accidentally overwriting things I didn't mean to touch.
That's the first thing we're going to fix this week. You've been using lists for everything — and lists let you change anything, anytime. But some data shouldn't change. A product's SKU, its unit weight, its dimensions — those are fixed specifications. Python has a structure built for exactly that.
The thing that crashes if you try to change it?
Tuple. And it's not just immutability — it's a signal to every person reading your code that this data is fixed by design. We'll also hit sets this week, which solve a problem you've definitely faced: finding unique values without writing a loop.
Wait. I don't have to write a loop for that? I've been doing if item not in seen_list for months.
For months. And we're going to fix that on day two. By the end of the week you'll have tuples, sets, unpacking, and named tuples — and the warehouse data will stop fighting back.
Named tuples sound like what I actually want. Can I access fields by name instead of index?
Exactly that. Here's a preview:
from collections import namedtuple
Product = namedtuple('Product', ['name', 'sku', 'weight', 'category'])
widget = Product('Widget-A', 'SKU-1001', 2.5, 'Electronics')
print(widget.category) # 'Electronics'Fixed. Readable. Named. You'll build that by day seven.
You already know lists. You used them for everything in Python Fundamentals — sales records, customer names, report rows. Lists are flexible and that flexibility served you well when you were learning. But warehouse inventory data has a property that sales row data does not: some of it is fixed by contract.
A product specification — name, SKU, unit weight, dimensions, category — does not change between the moment it enters your system and the moment it leaves. If the weight field in your pipeline gets overwritten, you're not looking at updated data. You're looking at a corruption. The list allowed the overwrite silently. That is what lists do.
Python's answer is the tuple: an ordered sequence like a list, but immutable after creation. Trying to change an element raises a TypeError at runtime, not a silent wrong answer hours later. Tuples are not a lesser list. They communicate intent — this data is fixed — and Python enforces that intent mechanically so you don't have to.
The second gap this week is deduplication. When you load category names from a warehouse CSV, you get every category for every row, including repeats. Finding unique values with a for-loop is correct but noisy. Python ships a built-in type — the set — that enforces uniqueness by definition. Passing a list to set() collapses duplicates in a single operation and gives you fast membership testing with in.
The third concept is unpacking: binding multiple variables from a sequence in one line. When a function returns a tuple of results, you can write name, sku, price = product_spec() instead of three index accesses. It reads like English and Python executes it as a single assignment. Extended unpacking with * lets you capture a variable-length middle section — useful for shipment records where the format isn't always the same length.
Named tuples close the week. They combine the immutability of tuples with the readability of field names. Instead of spec[2] you write spec.weight. Instead of hoping the fourth field is always category, you say spec.category and Python verifies the field exists. You get the safety of a tuple and the clarity of a small data class with no overhead.
By Friday you will have the tools to represent warehouse product specifications in a way that Python actively defends.
Sign up to save your notes.
Welcome back. You finished Track 1 — the Monday report runs, Diane is happy, and now the warehouse team has a pile of spreadsheets they want you to fix. How are you feeling about it?
Honestly? Pretty confident. I know how to loop, write functions, read CSVs. But the warehouse data is messier than the sales data. Product specs have like six fields and I keep accidentally overwriting things I didn't mean to touch.
That's the first thing we're going to fix this week. You've been using lists for everything — and lists let you change anything, anytime. But some data shouldn't change. A product's SKU, its unit weight, its dimensions — those are fixed specifications. Python has a structure built for exactly that.
The thing that crashes if you try to change it?
Tuple. And it's not just immutability — it's a signal to every person reading your code that this data is fixed by design. We'll also hit sets this week, which solve a problem you've definitely faced: finding unique values without writing a loop.
Wait. I don't have to write a loop for that? I've been doing if item not in seen_list for months.
For months. And we're going to fix that on day two. By the end of the week you'll have tuples, sets, unpacking, and named tuples — and the warehouse data will stop fighting back.
Named tuples sound like what I actually want. Can I access fields by name instead of index?
Exactly that. Here's a preview:
from collections import namedtuple
Product = namedtuple('Product', ['name', 'sku', 'weight', 'category'])
widget = Product('Widget-A', 'SKU-1001', 2.5, 'Electronics')
print(widget.category) # 'Electronics'Fixed. Readable. Named. You'll build that by day seven.
You already know lists. You used them for everything in Python Fundamentals — sales records, customer names, report rows. Lists are flexible and that flexibility served you well when you were learning. But warehouse inventory data has a property that sales row data does not: some of it is fixed by contract.
A product specification — name, SKU, unit weight, dimensions, category — does not change between the moment it enters your system and the moment it leaves. If the weight field in your pipeline gets overwritten, you're not looking at updated data. You're looking at a corruption. The list allowed the overwrite silently. That is what lists do.
Python's answer is the tuple: an ordered sequence like a list, but immutable after creation. Trying to change an element raises a TypeError at runtime, not a silent wrong answer hours later. Tuples are not a lesser list. They communicate intent — this data is fixed — and Python enforces that intent mechanically so you don't have to.
The second gap this week is deduplication. When you load category names from a warehouse CSV, you get every category for every row, including repeats. Finding unique values with a for-loop is correct but noisy. Python ships a built-in type — the set — that enforces uniqueness by definition. Passing a list to set() collapses duplicates in a single operation and gives you fast membership testing with in.
The third concept is unpacking: binding multiple variables from a sequence in one line. When a function returns a tuple of results, you can write name, sku, price = product_spec() instead of three index accesses. It reads like English and Python executes it as a single assignment. Extended unpacking with * lets you capture a variable-length middle section — useful for shipment records where the format isn't always the same length.
Named tuples close the week. They combine the immutability of tuples with the readability of field names. Instead of spec[2] you write spec.weight. Instead of hoping the fourth field is always category, you say spec.category and Python verifies the field exists. You get the safety of a tuple and the clarity of a small data class with no overhead.
By Friday you will have the tools to represent warehouse product specifications in a way that Python actively defends.