newbie question: why are python strings and tuples are made immutable?

Question

a newbie question.

i am not sure why strings and tuples were made to be immutable; what are the advantages and disadvantage of making them immutable?

please be gentle as it is a newbie question ;-)

thanks & wish you a good day!!

Answer 1

One is performance: knowing that a string is immutable makes it easy to lay it out at construction time — fixed and unchanging storage requirements. This is also one of the reasons for the distinction between tuples and lists. This also allows the implementation to safely reuse string objects. For example, the CPython implemenation uses pre-allocated objects for single-character strings, and usually returns the original string for string operations that doesn’t change the content.

The other is that strings in Python are considered as "elemental" as numbers. No amount of activity will change the value 8 to anything else, and in Python, no amount of activity will change the string “eight” to anything else.

http://effbot.org/pyfaq/why-are-python-strings-immutable.htm

Answer 2

pros: performance cons: you can't change them.

Answer 3

One big advantage of making them immutable is that they can be used as keys in a dictionary. I'm sure the internal data structures used by dictionaries would get quite messed up if the keys were allowed to change.

Answer 4

Imagine a language called FakeMutablePython, where you can alter strings using list assignment and such (such as mystr[0] = 'a')

a = "abc"

That creates an entry in memory in memory address 0x1, containing "abc", and the identifier a pointing to it.

Now, say you do..

b = a

This creates the identifier b and also points it to the same memory address of 0x1

Now, if the string were mutable, and you change b:

b[0] = 'z'

This alters the first byte of the string stored at 0x1 to z.. Since the identifier a is pointing to here to, thus that string would altered also, so..

print a
print b

..would both output zbc

This could make for some really weird, unexpected behaviour. Dictionary keys would be a good example of this:

mykey = 'abc'
mydict = {
    mykey: 123,
    'zbc': 321
}

anotherstring = mykey
anotherstring[0] = 'z'

Now in FakeMutablePython, things become rather odd - you initially have two keys in the dictionary, "abc" and "zbc".. Then you alter the "abc" string (via the identifier anotherstring) to "zbc", so the dict has two keys, "zbc" and "zbc"...

One solution to this weirdness would be, whenever you assign a string to an identifier (or use it as a dict key), it copies the string at 0x1 to 0x2.

This prevents the above, but what if you have a string that requires 200MB of memory?

a = "really, really long string [...]"
b = a

Suddenly your script takes up 400MB of memory? This isn't very good.

What about if we point it to the same memory address, until we modify it? Copy on write. The problem is, this can be quite complicated to do..

This is where immutability comes in.. Instead of requiring the .replace() method to copy the string from memory into a new address, then modify it and return.. We just make all strings immutable, and thus the function must create a new string to return. This explains the following code:

a = "abc"
b = a.replace("a", "z")

And is proven by:

>>> a = 'abc'
>>> b = a
>>> id(a) == id(b)
True
>>> b = b.replace("a", "z")
>>> id(a) == id(b)
False

(the id() function returns the memory address of the object)

Answer 5

Immutable types are conceptually much simpler than mutable ones. For example, you don't have to mess with copy constructors or const-correctness like in C++. The more types are immutable, the easier the language gets. Thus the easiest languages are the pure functional ones without any global state (because lambda calculus is much easier than Turing machines, and equally powerful), although a lot of people don't seem to appreciate this.