How does mutability in python work? What can happen when mutability goes wrong? This talk covers mutability in Python and how it can cause common bugs in Python. We cover some terrible (or "evil") mutable code. We then cover some safer, if not still questionable, "good" mutable code to show how it could be used to create powerful features in Python.

1. Mutability
For Good not Evil
Nick Sarbicki

2. Mutability
For Good not Evil
In nonlocal and global scope

3. Mutability
For Good(?) not Evil
In nonlocal and global scope

4. What is mutability?

5. What is mutability
A mutable object is an object which can be changed “in-place”.
Changing the state of a mutable object updates all variables referencing it.
An immutable object cannot be changed “in-place”.
Changing an immutable object creates a new object for a single variable.

6. []
Var A
Var B
Mutable types

7. []
Var A
Var B
>>> A.append(1)
Mutable types

8. [] [1]
Var A
Var B
>>> A.append(1)
Var A
Var B
Mutable types

9. “a”
Var A
Var B
Immutable types

10. “a”
Var A
Var B
>>> A += “b”
Immutable types

11. “a”
“ab”Var A
Var B
>>> A += “b”
Var A
Var B
Immutable types
“a”

12. What is the issue with mutability?
Mutability is simple on the surface.
However it is a powerful feature of Python that can be misleading.
Without understanding it properly it can lead to strange bugs.

13. Example - Shared References

14. Shared references cause problems
Sharing references to objects can cause unexpected results. It’s always best to
avoid sharing references if you don’t need to.
>>> my_list_of_lists = [[]] * 8
>>> my_list_of_lists
[[], [], [], [], [], [], [], []]
>>> my_list_of_lists[0].append(1)
>>> my_list_of_lists
[[1], [1], [1], [1], [1], [1], [1], [1]]

15. Shared references cause problems
[]
board[0]
>>> board[0].append(1)
board[1]
board[2]
board[3]
board[4]
board[5]
board[6]
board[7]
[1]
board[0]
board[1]
board[2]
board[3]
board[4]
board[5]
board[6]
board[7]

16. So we just need to watch out for it?
Yes and no.
Understanding and recognising mutability is very important.
Making it obvious is a good way of doing this.

17. Which is more obvious?
state = []
def append_data(data):
state.append(data)
if __name__ == ‘__main__’:
append_data(1)
state = []
def append_data(data, state):
state.append(data)
return state
if __name__ == ‘__main__’:
state = append_data(1, state)

18. Which is more obvious?
class StatefulClass:
def __init__(self, data):
self.data = data
self.state = []
def append_data(self):
self.state.append(self.data)
def run(self):
self.append_data()
class StatefulClass:
def __init__(self, data):
self.data = data
self.state = []
def append_data(self, state):
state.append(self.data)
return state
def run(self):
self.state = self.append_data(self.state)

19. Understand when to use it as well!

20. Mutable default Arguments
Mutable default arguments are a common GOTCHA in Python as they can change
the expected output of a function in misleading ways.
def func(a, b=[]):
b.append(a)
return b
>>> my_list = func(1)
>>> my_list
[1]
>>> my_new_list = func(1)
>>> my_new_list
[1, 1]

21. A possible use case for mutable default arguments?
Solving a circular dependency...
# a.py
from b import b1
def a1():
print('hi')
def a2():
b1()
if __name__ == '__main__':
a2()
# b.py
from a import a1
def b1():
a1()
print('there')
if __name__ == '__main__':
b1()

22. A possible use case for mutable default arguments?
Solving a circular dependency...
# a.py
from b import b1
def a1():
print('hi')
def a2():
b1(a1)
b1()
if __name__ == '__main__':
a2()
# b.py
def b1(func=None, callables=[]):
if func is not None:
callables.append(func)
return
for callable in callables:
callable()
print('there')
if __name__ == '__main__':
b1()

23. Is this good code?

25. Is there a good use for mutable default arguments?
Mutable default arguments can solve a lot of problems.
But they are rarely the right way to solve those problems.
Some arguments for memoization and binding in local scope.
Avoid if possible.

26. So what is a good use of mutability?

27. Reimplementing the circular dependency
solution

28. Reimplementing the circular dependency solution
def function_register(func):
callables = [] # <-- Mutable state goes here
class FunctionRegister:
def register_pre_call(self, callable):
callables.append(callable)
return callable
def __call__(self, *args, **kwargs):
for callable in callables:
callable()
return func(*args, **kwargs)
return FunctionRegister()

29. Reimplementing the circular dependency solution
from function_register import function_register
@function_register
def b():
print('there')
@b.register_pre_call
def a():
print('hi')
if __name__ == '__main__':
b()

30. Implementing memoization
def memoize(func):
calls = {} # ← Mutable state goes here
def wraps(*args, **kwargs):
key = (tuple(args), tuple(kwargs.items()))
try:
return calls[(tuple(args), tuple(kwargs.items()))]
except KeyError:
ret_val = func(*args, **kwargs)
calls[key] = ret_val
return ret_val
return wraps

31. In Conclusion

32. So in conclusion
Avoid shared references.
Avoid default mutable arguments.
But don’t avoid mutability in nonlocal scope.
Keep your code obvious.
Don’t overcomplicate things.

33. Thanks!
Nick Sarbicki
Nick.Sarbicki.com
(github/gitlab.com)/ndevox
@NDevox