Session 18 - Mutability & Aliasing

Discussion prompt

Before we open Session 18 - Mutability & Aliasing: without looking back, what was the main idea of Session 17 - Comprehensions, and what could you do by the end of it that you could not do before?

Hint: One sentence for the idea, one for the skill. If the second one is blank, that is the part to revisit.

Discussion prompt

A variable is not a box that holds a value. It is a label stuck onto an object that lives elsewhere in memory.

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Discussion prompt

Explain Assignment binds; it does not copy by analogy to something with no Python Fundamentals in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Put in order

Put the moves of Two names, one list into the order they have to happen.

1. Line 2 binds b to the same list
2. Line 3 mutates that one list through b
3. Read the output

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. No new list is made - b is just a second label on a's list.

Comparison matrix

From Two names, one list: refill the a column from what you know. The rest of the table is as it appeared.

Fill in the blanks

From A dictionary with two names — one line has had its right-hand side removed. Put it back.

prices = prices
alias = ___
alias["pen"] = 99
print(prices)

Why: alias is what everything below it consumes, so the wrong expression here fails later and somewhere else. No new dict is made - alias and prices point at one dictionary.

Comparison matrix

From A dictionary with two names: every row here is a choice with a cost. Fill the prices[pen] column, then say which row you would actually pick and what you give up for it.

Discussion prompt

Explain Two sticky notes on one folder to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Sort into buckets

Every line below is part of the definition of binding or of alias — one or the other, never both. Put each where it belongs.

binding

Attaching a name to an object.; a = [1, 2, 3] binds the name a to a list object.; The name is not the object - it just points at it.

alias

A second name for the same object.; Aliases share every in-place change; because there is only one object underneath.

b1

Attaching a name to an object. a = [1, 2, 3] binds the name a to a list object. The name is not the object - it just points at it.

b2

A second name for the same object. Aliases share every in-place change, because there is only one object underneath.

Annotate

Walk the callouts on is proves they are the same object. Each one is a place this is easy to get subtly wrong.

• So id(a) and id(b) are the same number - one object, one address.
• Verified by execution: id(a) == id(b) is True, and a is b is True.

Predict first

The table runs: a == b | True · a is b | False

In Equal but not identical, given the rows so far: what is the next one — the row where expression is id(a) == id(b)?

Correct: id(a) == id(b) | False

Why: The relationship between the columns, not the individual numbers, is what generates the next row. Each [1, 2, 3] builds a fresh object; no aliasing here.

Step through it

Step through Equal but not identical one row at a time. What is driving the change, and what would the row after the last one be?

1. Step 1: expression is a == b
2. Step 2: expression is a is b
3. Step 3: expression is id(a) == id(b)

Discussion prompt

Reassigning an int makes a new object — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: y = x points y at the int 10

Step through it

Step through Reassigning an int makes a new object one row at a time. One of these columns never changes — find it, and say why it cannot.

1. Step 1: line is x = 10
2. Step 2: line is y = x
3. Step 3: line is y = y + 1

Sort into buckets

These are the pieces of Session 18 - Mutability & Aliasing, out of order. Put each one back under the part of the lesson it belongs to.

Names Are Labels

A name points at an object; Assignment binds; it does not copy; Two names, one list

Proving It With id()

id() is the object's address; is proves they are the same object; Same twin, or just look-alikes?

Mutable vs Immutable

Some objects can change in place; Reassigning an int makes a new object; Why aliasing only bites with mutables

s1

Names Are Labels is where Session 18 - Mutability & Aliasing puts A name points at an object, Assignment binds; it does not copy, Two names, one list. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

s2

Proving It With id() is where Session 18 - Mutability & Aliasing puts id() is the object's address, is proves they are the same object, Same twin, or just look-alikes?. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

s3

Mutable vs Immutable is where Session 18 - Mutability & Aliasing puts Some objects can change in place, Reassigning an int makes a new object, Why aliasing only bites with mutables. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

Draw it

Draw what Strings cannot be edited in place just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.

Fill in the blanks

list.copy() makes a separate list, with the scaffolding fading: two lines are gone now — fill both.

a = [1, 2, 3]
b = a.copy()
b.append(4)
print(a)
print(b)
print(a is b)

Why: Reproducing these unaided, rather than reading them, is what tells you the method has transferred. b points at a fresh object with the same contents - not at a's list.

Fill in the blanks

From dict.copy() for dictionaries — one line has had its right-hand side removed. Put it back.

prices = prices.copy()
copy_prices = ___
copy_prices["pen"] = 99
print(prices)
print(copy_prices)

Why: copy_prices is what everything below it consumes, so the wrong expression here fails later and somewhere else. copy_prices is a separate dictionary with the same key/value pairs.

Discussion prompt

Contrast: alias vs copy in one run — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: b aliases a; c is a copy

Step through it

Step through Contrast: alias vs copy in one run one row at a time. What is driving the change, and what would the row after the last one be?

1. Step 1: line is c = a.copy()
2. Step 2: line is b.append(3)
3. Step 3: line is c.append(4)

Match the pairs

Match each term to the definition this lesson gave it — not the one you would guess from the word.

• t1. binding
• t2. alias
• t3. id() and is
• t4. mutable / immutable
• t5. shallow copy

• d1. Attaching a name to an object. a = [1, 2, 3] binds the name a to a list object. The name is not the object - it just points at it.
• d2. A second name for the same object. Aliases share every in-place change, because there is only one object underneath.
• d3. id(x) gives an object's identity number. x is y is True when x and y point at the same object - equivalent to id(x) == id(y).
• d4. Mutable = can be altered in place (list, dict, set). Immutable = cannot change; any 'change' actually builds a new object (int, str, tuple).
• d5. A new top-level container whose elements still point at the original nested objects. Only the outer layer is duplicated.

Why: These are the working definitions of binding, alias, id() and is, mutable / immutable, shallow copy as Session 18 - Mutability & Aliasing uses them. Pairing them correctly is the test of whether you could state each one with the slide switched off.

Put in order

Put the moves of The nested list is still shared into the order they have to happen.

1. shallow is a new outer list
2. But shallow[0] is outer[0] - same inner list
3. Mutating the inner list shows in both

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. outer is shallow would be False - the outer container was copied.

Predict first

The table runs: outer after append | [[1, 2], [3, 4]] · deep after append | [[1, 2, 99], [3, 4]]

In deepcopy breaks the sharing, given the rows so far: what is the next one — the row where check is outer[0] is deep[0]?

Correct: outer[0] is deep[0] | False

Why: The relationship between the columns, not the individual numbers, is what generates the next row. deep[0] is a brand-new inner list, not outer[0].

Comparison matrix

From deepcopy breaks the sharing: refill the result column from what you know. The rest of the table is as it appeared.

Predict first

A student writes this, and it looks reasonable:

A dict holds a list, and .copy() feels safe.

It is wrong. Say what breaks — and say it before you turn the page.

Correct: dict.copy() duplicated the outer dict, but 'scores' in both points at the SAME list.

Use deepcopy when the data is nested.

Why: dict.copy() duplicated the outer dict, but 'scores' in both points at the SAME list. Appending through one shows in both.

Discussion prompt

A function changes the caller's list — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: nums is bound to scores' list

Fill in the blanks

Rebind vs mutate inside a function, with the scaffolding fading: two lines are gone now — fill both.

def rebind(nums):
nums = nums + [0]
print("inside:", nums)

scores = [10, 20, 30]
rebind(scores)
print("outside:", scores)

Why: Reproducing these unaided, rather than reading them, is what tells you the method has transferred. The + makes a new list and rebinds the local name nums to it.

Predict first

A student writes this, and it looks reasonable:

You reach for += thinking it is a safe rebind.

It is wrong. Say what breaks — and say it before you turn the page.

Correct: For lists, nums += [99] is the same as nums.extend([99]) - it mutates the shared object, so the caller changes.

To leave the caller alone, build a new list with +.

Why: For lists, nums += [99] is the same as nums.extend([99]) - it mutates the shared object, so the caller changes.

Discussion prompt

The rule this trap just fixed:

The + builds a new list and points the local name at it; scores is untouched. Verified: scores stays [1, 2].

Now break it on purpose. Build a case that violates it and follow the consequences until something visibly fails. Where does the failure first show up — and would you have noticed it if you had not been looking?

Hint: The dangerous rules are the ones whose violation still produces an answer. If yours fails loudly, try to find one that fails quietly.

Discussion prompt

The list that will not reset — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: cart=[] is built once at definition

Discussion prompt

Explain The default is baked into the recipe to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Discussion prompt

Explain The fix: default to None by analogy to something with no Python Fundamentals in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Put in order

Put the moves of None default gives a fresh list each call into the order they have to happen.

1. Default is None, an immutable sentinel
2. Build a new list inside when cart is None
3. Read the output

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. None cannot accumulate; it just signals 'no cart was given'.

Draw it

Draw what None default gives a fresh list each call just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.

Predict first

A student writes this, and it looks reasonable:

A history list as a default quietly persists.

It is wrong. Say what breaks — and say it before you turn the page.

Correct: It never empties, so len keeps climbing - the count leaks between unrelated calls.

Default to None and make the list inside.

Why: It never empties, so len keeps climbing - the count leaks between unrelated calls.

Sort into buckets

Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.

Holds up

A variable is not a box that holds a value. It is a label stuck onto an object that lives elsewhere in memory.; b = a does not make a new object. It sticks a second label, b, onto the same object a already points at.; Picture a physical folder on a desk. A name is a sticky note with an arrow pointing at that folder.

Breaks

A dict holds a list, and .copy() feels safe.; You reach for += thinking it is a safe rebind.

sound

These are stated as this lesson states them — each one survives the edge cases Session 18 - Mutability & Aliasing puts it through.

flawed

Each of these is lifted from a trap in this deck: reasonable-sounding, and wrong in a way that only shows up once you rely on it.

Discussion prompt

Everything so far applies to every mutable type. alias = my_dict or also = my_set binds a second name to the same object - mutate through one, see it in both.

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Annotate

Walk the callouts on A set with two names. Each one is a place this is easy to get subtly wrong.

• One set, two labels - sets are mutable, so this shares like a list.
• Verified by execution: sorted(tags) is ['blue', 'green', 'red']. (sorted just gives a stable order to print.)

Fill in the blanks

From clear() empties it for every alias — one line has had its right-hand side removed. Put it back.

data = [1, 2, 3]
backup = data
data.clear()
print(data)
print(backup)

Why: backup is what everything below it consumes, so the wrong expression here fails later and somewhere else. But backup = data is an alias, not a copy - both names point at one list.

Comparison matrix

From clear() empties it for every alias: every row here is a choice with a cost. Fill the backup column, then say which row you would actually pick and what you give up for it.

Discussion prompt

Outside this lesson: where does Session 18 - Mutability & Aliasing actually turn up? Name one concrete situation — a job, a piece of software someone ships, a decision somebody has to make — and say which part of Safe function parameters is doing the work in it.

Hint: Vague is the failure mode here. "Engineering" is not a situation; "deciding whether this build is fast enough to ship" is.

Check your understanding

What does this print?

• A. [1, 2, 3, 4] (correct)
• B. [1, 2, 3]
• C. [4]
• D. [1, 2, 3, 4, 4]

Answer: A

Why: b = a binds b to the same list, so b.append(4) mutates the one shared object and a sees it. Verified by execution.

Why B tempts people

That would need b to be a copy. b = a is an alias, so a and b are the same list.

Why C tempts people

append adds to the existing list; it does not replace it with [4].

Why D tempts people

append runs once, adding a single 4 to one shared list - not two 4s.

Check your understanding

What does this print?

• A. [1, 2, 3] (correct)
• B. [1, 2, 3, 4]
• C. [1, 2, 3, 4, 4]
• D. []

Answer: A

Why: a.copy() builds a separate list, so appending to b cannot touch a. a stays [1, 2, 3]. Verified by execution.

Why B tempts people

That is b's value. Because b is a copy, a is unchanged at [1, 2, 3].

Why C tempts people

Only b grows, and only by one element; a never changes at all.

Why D tempts people

copy() duplicates the contents, so a is not emptied - it keeps [1, 2, 3].

Check your understanding

What does this print?

• A. True False (correct)
• B. True True
• C. False False
• D. False True

Answer: A

Why: The lists have equal contents, so == is True; but they are two separate objects, so is is False. Verified by execution.

Why B tempts people

is would be True only if a and b were the same object. Typed-out literals build two objects.

Why C tempts people

== compares contents, which match here, so == is True - not False.

Why D tempts people

This reverses both: equal contents give == True, and separate objects give is False.

Check your understanding

What does this print?

• A. [[1, 2, 9], [3, 4]] (correct)
• B. [[1, 2], [3, 4]]
• C. [[1, 2], [3, 4, 9]]
• D. [[1, 2, 9], [3, 4, 9]]

Answer: A

Why: copy() is shallow: s is a new outer list, but s[0] is still the same inner list as outer[0], so appending 9 shows in outer. Verified by execution.

Why B tempts people

The inner list is shared, so the append does reach outer - it does not stay unchanged.

Why C tempts people

append(9) targets index 0, the first inner list, not the second.

Why D tempts people

Only s[0] is appended to; the second inner list is never touched.

Check your understanding

What does this print?

• A. [1, 2, 0] (correct)
• B. [1, 2]
• C. None
• D. [0]

Answer: A

Why: nums is bound to the same list as scores, so nums.append(0) mutates it in place and scores becomes [1, 2, 0]. Verified by execution.

Why B tempts people

The list is passed by binding, not copied, so the in-place append does reach scores.

Why C tempts people

print(scores) shows the list, not the function's return value - scores is a real list.

Why D tempts people

append adds to the existing contents; it does not replace the list with [0].

Check your understanding

What does the print show?

• A. [1, 2] (correct)
• B. [2]
• C. [1]
• D. [1, 1, 2]

Answer: A

Why: The default acc is created once and shared. f(1) leaves it [1]; f(2) appends to the same list, giving [1, 2]. Verified by execution.

Why B tempts people

acc does not reset between calls - the earlier 1 is still there, so it is [1, 2].

Why C tempts people

f(2) appends 2 to the shared default, so the 2 is included.

Why D tempts people

Each call appends its own x exactly once; f(1) added one 1, not two.

Comparison matrix

From Check: mutable default: refill the acc column from what you know. The rest of the table is as it appeared.

Draw it

One page, no notation unless you need it: draw how these connect — Names Are Labels · Proving It With id() · Mutable vs Immutable · Making a Real Copy · Shallow vs Deep · Functions Mutate Your List. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.