Python TutorialGetting Started with PythonPython Basic SyntaxPython DatatypesPython IndentationPython Collection TypesPython Basic Input and OutputPython Built in Modules and FunctionsPython FunctionsChemPy - python packageCreating Python packagesFunctional Programming in PythonIncompatibilities moving from Python 2 to Python 3IoT Programming with Python and Raspberry PIKivy - Cross-platform Python Framework for NUI DevelopmentMutable vs Immutable (and Hashable) in PythonPyInstaller - Distributing Python CodePython *args and **kwargsPython 2to3 toolPython Abstract Base Classes (abc)Python Abstract syntax treePython Alternatives to switch statement from other languagesPython and ExcelPython Anti-PatternsPython ArcPyPython ArraysPython Asyncio ModulePython Attribute AccessPython AudioPython Binary DataPython Bitwise OperatorsPython Boolean OperatorsPython Checking Path Existence and PermissionsPython ClassesPython CLI subcommands with precise help outputPython Code blocks, execution frames, and namespacesPython Collections modulePython Comments and DocumentationPython Common PitfallsPython Commonwealth ExceptionsPython ComparisonsPython Complex mathPython concurrencyPython ConditionalsPython configparserPython Context Managers (with Statement)Python Copying dataPython CountingPython ctypesPython Data SerializationPython Data TypesPython Database AccessPython Date and TimePython Date FormattingPython DebuggingPython DecoratorsPython Defining functions with list argumentsPython DeploymentPython Deque ModulePython DescriptorPython Design PatternsPython DictionaryPython Difference between Module and PackagePython DistributionPython DjangoPython Dynamic code execution with `exec` and `eval`Python EnumPython ExceptionsPython ExponentiationPython Files & Folders I/OPython FilterPython FlaskPython Functools ModulePython Garbage CollectionPython GeneratorsPython getting start with GZipPython graph-toolPython groupby()Python hashlibPython HeapqPython Hidden FeaturesPython HTML ParsingPython HTTP ServerPython IdiomsPython ijsonPython Immutable datatypes(int, float, str, tuple and frozensets)Python Importing modulesPython Indexing and SlicingPython Input, Subset and Output External Data Files using PandasPython Introduction to RabbitMQ using AMQPStorm

Mutable vs Immutable (and Hashable) in Python

From WikiOD

Mutable vs Immutable[edit | edit source]

There are two kind of types in Python. Immutable types and mutable types.

Immutables[edit | edit source]

An object of an immutable type cannot be changed. Any attempt to modify the object will result in a copy being created.

This category includes: integers, floats, complex, strings, bytes, tuples, ranges and frozensets.

To highlight this property, let's play with the id builtin. This function returns the unique identifier of the object passed as parameter. If the id is the same, this is the same object. If it changes, then this is another object. (Some say that this is actually the memory address of the object, but beware of them, they are from the dark side of the force...)

>>> a = 1
>>> id(a)
>>> a += 2
>>> a
>>> id(a)

Okay, 1 is not 3... Breaking news... Maybe not. However, this behaviour is often forgotten when it comes to more complex types, especially strings.

>>> stack = "Overflow"
>>> stack
>>> id(stack)
>>> stack += " rocks!"
>>> stack
'Overflow rocks!'

Aha! See? We can modify it!

>>> id(stack)

No. While it seems we can change the string named by the variable stack, what we actually do, is creating a new object to contain the result of the concatenation. We are fooled because in the process, the old object goes nowhere, so it is destroyed. In another situation, that would have been more obvious:

>>> stack = "Stack"
>>> stackoverflow = stack + "Overflow"
>>> id(stack)
>>> id(stackoverflow)

In this case it is clear that if we want to retain the first string, we need a copy. But is that so obvious for other types?

Exercise[edit | edit source]

Now, knowing how a immutable types work, what would you say with the below piece of code? Is it wise?

s = ""
for i in range(1, 1000):
    s += str(i)
    s += ","

Mutables[edit | edit source]

An object of a mutable type can be changed, and it is changed in-situ. No implicit copies are done.

This category includes: lists, dictionaries, bytearrays and sets.

Let's continue to play with our little id function.

>>> b = bytearray(b'Stack')
>>> b
>>> b = bytearray(b'Stack')
>>> id(b)
>>> b += b'Overflow'
>>> b
>>> id(b)

(As a side note, I use bytes containing ascii data to make my point clear, but remember that bytes are not designed to hold textual data. May the force pardon me.)

What do we have? We create a bytearray, modify it and using the id, we can ensure that this is the same object, modified. Not a copy of it.

Of course, if an object is going to be modified often, a mutable type does a much better job than an immutable type. Unfortunately, the reality of this property is often forgotten when it hurts the most.

>>> c = b
>>> c += b' rocks!'
>>> c
bytearray(b'StackOverflow rocks!')


>>> b
bytearray(b'StackOverflow rocks!')

Waiiit a second...

>>> id(c) == id(b)

Indeed. c is not a copy of b. c is b.

Exercise[edit | edit source]

Now you better understand what side effect is implied by a mutable type, can you explain what is going wrong in this example?

>>> ll = [ [] ]*4 # Create a list of 4 lists to contain our results
>>> ll
[[], [], [], []]
>>> ll[0].append(23) # Add result 23 to first list
>>> ll
[[23], [23], [23], [23]]
>>> # Oops...

Mutable and Immutable as Arguments[edit | edit source]

One of the major use case when a developer needs to take mutability into account is when passing arguments to a function. This is very important, because this will determine the ability for the function to modify objects that doesn't belong to its scope, or in other words if the function has side effects. This is also important to understand where the result of a function has to be made available.

>>> def list_add3(lin):
    lin += [3]
    return lin

>>> a = [1, 2, 3]
>>> b = list_add3(a)
>>> b
[1, 2, 3, 3]
>>> a
[1, 2, 3, 3]

Here, the mistake is to think that lin, as a parameter to the function, can be modified locally. Instead, lin and a reference the same object. As this object is mutable, the modification is done in-place, which means that the object referenced by both lin and a is modified. lin doesn't really need to be returned, because we already have a reference to this object in the form of a. a and b end referencing the same object.

This doesn't go the same for tuples.

>>> def tuple_add3(tin):
    tin += (3,)
    return tin

>>> a = (1, 2, 3)
>>> b = tuple_add3(a)
>>> b
(1, 2, 3, 3)
>>> a
(1, 2, 3)

At the beginning of the function, tin and a reference the same object. But this is an immutable object. So when the function tries to modify it, tin receive a new object with the modification, while a keeps a reference to the original object. In this case, returning tin is mandatory, or the new object would be lost.

Exercise[edit | edit source]

>>> def yoda(prologue, sentence):
    prologue += " ".join(sentence)
    return prologue

>>> focused = ["You must", "stay focused"]
>>> saying = "Yoda said: "
>>> yoda_sentence = yoda(saying, focused)

Note: reverse operates in-place.

What do you think of this function? Does it have side effects? Is the return necessary? After the call, what is the value of saying? Of focused? What happens if the function is called again with the same parameters?