Home / Questions / 461284
Accepted
PySanti
Asked: 2022-06-12 08:34:36 +0800 CST 2022-06-12 08:34:36 +0800 CST

Mutability vs Immutability (Python)

  • 772

Through this question, I would like to know what is the difference between mutability and immutability in Python, beyond the fact that some can be modified and others cannot . I pose the question for two reasons:

1-I am quite curious about the fact that some iterable objects in Python only support immutable objects (dictionaries, sets, etc...). I can come to understand in the case of dictionaries that it is for example so that the programmer does not accidentally change the key of some value, and subsequently does not know why he cannot access the dictionary, but what about sets, why don't support mutable objects?

2-In a part of the documentation , right at the beginning of the explanation of the dictionaries), it says the following...

The keys of a dictionary can be of almost any type. Values ​​that are not hashable, such as values ​​that contain lists, dictionaries, or other mutable types (that are compared by value, not by reference), cannot be used as keys."

This means that mutable objects are compared by value and not by reference, and immutable objects do exactly the opposite. And this makes sense when we look at Python's behavior in assigning values. When dealing with strings, Python checks if the value is in the internal string table , and we can see this in the following example:

>>> a = 'foo'
>>> b = 'foo'
>>> a is b
True

However, if we try it with any other data type, mutable or immutable, it doesn't work... (Note that in fact, when the strings are very long, the interpreter doesn't check the existence of underlying strings)

>>> a = 1
>>> b = 1
>>> a is b
True (ver modificacion)


>>> a = set([1])
>>> b = set([1])
>>> a is b
False

It's pretty clear that what happened to strings is due to pure chance (or that Python only searches for existing strings when the one being searched for is short??), since this only happens from time to time with strings and integers (see modification). The point is this: if immutable objects are compared by reference, why isn't there a larger reference passing system, in other words, why isn't the existence of underlying objects checked more often, precisely so that the comparison by reference be more exact .

Not to mention, that immutable objects are compared through references and not values, is not entirely clear...

>>> a = (1,2)
>>> b = (1,2)
>>> a == b
True
>>> a is b
False
>>> 


>>> a = frozenset([1,2])
>>> b = frozenset([1,2])
>>> a == b
True
>>> a is b
False

Finally, the question would be : what is the difference between the administration of mutable and immutable objects in Python, except that some can be modified and others cannot?

Modification: in the example of the integers, a is bsince the value 10is 'precreated' (like all numbers from -5 to 256), therefore when saying a = 10, ait will point to the 10one that already exists and the same happens with b, which generates that a is b( reference ).

python

2 Answers

  1. Best Answer

    I think the main problem is according to the definition of variable categories and their differences. I am going to try to focus mainly on the sequences because they are usually the type of variables in which you can find the most differences.

    Although initially they do not answer your questions, I believe that defining these concepts can help you to have a more complete vision of the panorama and to be able to delimit each category and what advantages they may imply.

    Note. At the end, the answers to the questions are presented.

    Sequences can be classified based on several parameters, one of these parameters is the type of variables that it can contain, from this two types of sequences are defined:

    1. Container sequences . They can store objects of different types. Some examples of this type of sequences are: list, tuple, etc.
    2. Flat sequences . It allows to store objects of the same type. Some examples of this type of sequences are: bytes, str, array, etc.

    From this classification, the only thing that is intended to be highlighted is the fact that flat sequences types can only contain one type of object, that is, the str type only contains characters while a container sequences can contain some nested structures in the same object, strings, integers, etc. The way in which a sequence can be of type container sequence is achieved conceptually through a structure similar to an array of pointers (in C), that is, a list is an array, where the first index points to the first object and this is where the difference in performance between these two types of sequences is mainly marked.

    1. To access an object inside a sequences container , first you have to read the memory address that is in the referenced index, once the memory address is obtained, you have to refer to it to actually get the object that matters to us
    2. In the case of flat sequences , the values ​​are directly stored in the index of the array, that is, we only have to go to the index of the array to know which is the value of the object that matters to us, it is not necessary the intermediate step of reading a extra memory address.

    Until now and due to the aforementioned operation, flat sequences have mainly two advantages:

    1. A flat sequence stores the values ​​as such, it does not need to store extra information to be able to refer to any type of object (as is the case with container sequences ), this translates into lower memory cost.
    2. Modern computers generally make use of various levels of cache based on the principle of locality, very narrowly meaning that when you read information from memory, this read not only brings back exactly what you want, but also brings back blocks or pages of data. memory containing information that is close to the one you are trying to get, this is extremely useful when you have arrays because arrays span adjoining memory addresses which means that when you read an index, you possibly have the values ​​of its neighboring indices cached. In the case of flat sequences , they are fully benefited by these mechanisms, while container sequencesThey are harmed because within each index they have a pointer that leads to the value, and this value is very possibly not close in terms of memory addresses, which is why it may be less likely that it is in the cache.

    Marking these main differences, there is also the classification according to the mutability of the structures.

    1. Mutable Sequences . They can be modified. Example: list, array, etc.
    2. Immutable Sequences . They cannot be modified. Example: str, tuple, etc.

    The main difference besides the fact that they can or cannot be modified is in their internal workings, for example the comparison between list and tuple is according to their performance, and this can be expressed in several ways:

    1. Tuples don't have to allocate extra memory because they can't be modified, instead lists must have a buffer of memory to amortize the action of expanding.
    2. There are optimizations to the bytecode generated by tuples that are not found in list variables .
    3. Making a copy with float(f)returns a reference to the same object.

    From the above, I want to emphasize that immutability does not only occur in sequences, it can also be spoken of variables of numerical type, however the comparison or the advantages that can be presented with this type of data are very specific to each circumstance, really it is not that strictly some category is compared by reference and another by value.

    Based on the above, I am going to begin to clarify some points that you mentioned.

    1-I am quite curious about the fact that some iterable objects in Python only support immutable objects (dictionaries, sets, etc...).

    This is not entirely true, dictionaries and sets do not only accept immutable objects as keys, in fact any instance of a user-defined class can be used as a key and it does not have to be immutable. The requirement for an object to be used as a key is that it be hashable, this means that:

    1. The object must implement the dunder method __hash__that returns the hash code that represents the object. In case it is an instance of a user-defined class, this method returns the value of the function idby default, that is, the memory address of the object.
    2. The object must implement the dunder method __eq__that must return a boolean value that determines if it is equal to another object. Each pair of objects returned Truewhen performing an equality comparison with __eq__, should also return the same hash code in their __hash__. In case it is an instance of a user-defined class, this method returns the value of the function idby default, that is, the memory address of the object.

    The need for both methods to be defined is mainly due to how dictionaries work and how collisions are handled in their hash codes.

    Note. Clearly, it would not make much sense to define a Person class that uses the hash of the name field as a hash and that later modifies this field and tries to look up the object in the dictionary, I think that in this sense immutability is defined in this case.

    Last but not least...

    This means that mutable objects are compared by value and not by reference, and immutable objects do exactly the opposite. And this makes sense when we look at Python's behavior in assigning values. When dealing with strings, Python checks if the value is in the internal string table, and we can see this in the following example:

    The answer is no, regardless of whether the variable is mutable or immutable, you have two comparison methods.

    1. __eq__. Called by the operator ==and generally checks the equality of objects according to the values ​​it contains
    2. is. Compares two objects but by their reference (memory address).

    In short, it can be said that a variable is not a value or an object, it is a label or link to an object, several labels can point to the same object and when there are no labels pointing to an object or the only labels are from objects that are are pointing to each other, then these objects are removed by the interpreter using the garbage collector.

    So both types of objects can be compared either by value or by their reference(memory address) or label, the reason why you get this result:

    >>> a = 1
>>> b = 1
>>> a is b
True (ver modificacion)

    It is due to optimizations made by python, these depend on the version of python and are defined in the style of... the first 256 numbers are cached in memory, which is why any variable (label that points to them) will refer to the same object in memory, that's why the comparison with isis true.

    A similar optimization occurs with strings but in both cases you should not assume that these optimizations are always performed, it may vary between versions.

    • 1

  2. Let's do something quick, first you have to know that it iscompares if the variable points to the same object, but not if they contain the same value.

    Every time you assign a value to a variable, Python creates the object (mutable or immutable)

    In the case of immutable objects, as their name says, they cannot change their value, if we have a variable b=10and then add it, 1python does not replace the variable ba 11, but creates another object and then adds the values 10+1​​and finally creates another object and assigns the value 11to it, which does not happen with mutable objects. A very common example is to replace a position of a string, but being immutable, this will give you an error.

    string = "texto"
string[0] = "T"

    Mistake

    TypeError: 'str' object does not support item assignment

    In the case of mutable data, if you can do that, such as lists:

    lista = ["H","o","l","a"]
lista[0] = "h"

print(lista)
#salida-> ['h', 'o', 'l', 'a']

    Well now let's see what happens with the immutable data, according to your example:

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

>>> a is b
False

    This is totally correct and I show it to you with the following graph

    mutable_variables

    The two objects are created, each one with its respective value, none of the variables points to the same object, so when using it, isit will return you , Falsebut when using the purchase operator, ==the result will be True. We can make the variable point to the same object by making the corresponding assignment

    >>> a = (1,2)
>>> b = (1,2)
>>> a = b
>>> a is b
>>> True

    But with strings something different happens because here the internal string table comes into play, this is like a list or container that stores the created stings and you create another variable whose value is found here, the reference of this value will be returned to you. Let's look at the graph

    internal_string_table_explanation

    If we create the variables a,b,cwhere a="foo", b="bar"and c="foo"all these strings will be stored in the table of internal strings where if there is already a string with the value that is assigned to another, the new variable is only made to point to the same string, at the end the variables aand cpoint to the same object and for that reason.

    >>> a = 'foo'
>>> b = 'foo'
>>> a is b
True
    • 0