Mutable Defaults

1The program that surprises everyone

Here is a function that puts an item in a basket. If no basket is given, it starts an empty one:

def add_item(item, basket=[]):
    basket.append(item)
    return basket

print(add_item('pen'))
print(add_item('book'))
print(add_item('bag'))

['pen']
['pen', 'book']
['pen', 'book', 'bag']

Three separate calls, and the basket never emptied. Most people expect three lines each holding one item — ['pen'], ['book'], ['bag'] — because surely a fresh call makes a fresh basket?

2The list is made once, not once per call

Everything on the def line is worked out at the moment Python reads that line — and it reads it once. The [] is part of that line, so one empty list is created, once, and kept with the function for as long as the program runs.

You can watch it happen. Print the basket at the start of each call, before anything is added:

def add_item(item, basket=[]):
    print('basket at the start of this call:', basket)
    basket.append(item)
    return basket

add_item('pen')
add_item('book')
add_item('bag')

basket at the start of this call: []
basket at the start of this call: ['pen']
basket at the start of this call: ['pen', 'book']

It is empty on the first call only. By the second call the “empty basket” already has a pen in it, because it is the same basket the first call put the pen into. Nobody made a new one, because nothing asked for a new one to be made.

3The name is local. The list is not.

This is the sentence worth learning, so here it is slowly. A local variable is two things — a name and the object that name points at — and only the first of them belongs to the call.

Each call builds its own little workspace and puts the name basket in it. That name is thrown away when the call ends — but the name was only ever a label pointing at the list. The list itself lives with the function, not in the workspace, so it survives every call and carries the previous items with it.

And append does not touch the name at all. It reaches through the name and changes the list on the other end — the one every call is pointing at.

4Rebinding a name, and changing a thing

Python has two very different operations that both look like “the variable changed”, and telling them apart explains this whole lesson:

Swap append for an assignment and the surprise disappears completely — same default, same three calls:

def add_item(item, basket=[]):
    basket = basket + [item]      # a NEW list — the name now points at that
    return basket

print(add_item('pen'))
print(add_item('book'))
print(add_item('bag'))

['pen']
['book']
['bag']

Three separate answers, which is what everybody expected the first time. Print the basket at both ends of the call and you can see why:

def add_item(item, basket=[]):
    print('start of call:', basket)
    basket = basket + [item]      # a NEW list — the name now points at that
    print('end of call  :', basket)
    return basket

add_item('pen')
add_item('book')

start of call: []
end of call  : ['pen']
start of call: []
end of call  : ['book']

This is the same mutable / immutable idea from Class 11, and the same one behind n = n + 1 changing nothing outside a function while marks.append(m) changes everything. One moves a label; the other edits a thing.

5Why msg='Hello' never caused trouble

Every default is shared — the string in msg='Hello' is created once too. It causes no trouble because a string cannot be edited in place. There is no msg.append(…) to write. The only thing you can do to a string is build a new one and rebind:

def greet(name, msg='Hello'):
    msg = msg + '!'               # rebinding — the only option a string allows
    print(msg, name)

greet('Riya')
greet('Amit')

Hello! Riya
Hello! Amit

Both calls start from 'Hello', because nothing can reach into a string and change it. Numbers, strings, Booleans, None and tuples are all immutable, so all of them are safe as defaults. Lists, dictionaries and sets are not.

# a dictionary default has exactly the same problem

def tally(mark, marks={}):
    marks[mark] = marks.get(mark, 0) + 1
    return marks

print(tally('A'))
print(tally('B'))
print(tally('A'))

{'A': 1}
{'A': 1, 'B': 1}
{'A': 2, 'B': 1}

6The fix: an immutable default, and a fresh list inside

If you want a genuinely new list on every call, the list has to be created inside the body — because the body is the part that runs every time. The default becomes None, which is immutable and therefore safe, and the first line checks for it:

def add_item(item, basket=None):
    if basket is None:
        basket = []               # runs on every call that needs it
    basket.append(item)
    return basket

print(add_item('pen'))
print(add_item('book'))
print(add_item('bag'))

['pen']
['book']
['bag']

7Passing your own list is never affected

The sharing only happens when the argument is left out. Supply a basket and the default is not consulted at all:

def add_item(item, basket=[]):
    basket.append(item)
    return basket

print(add_item('pen'))                # uses the shared default
print(add_item('cap', ['own']))       # uses the caller's own list
print(add_item('book'))               # back to the shared default

['pen']
['own', 'cap']
['pen', 'book']

The middle call is completely separate. The last call carries on from ['pen'], because the shared list never saw the 'own' basket at all.

def add_item(item, basket=[]):
    basket.append(item)
    return basket

print(add_item('pen'))
print(add_item('book'))

# now change basket=[] to basket=None and add these two lines
# at the top of the body:
#     if basket is None:
#         basket = []
# then run it again and compare

8Recap