70
  1. What are the design reasons of making Python strings immutable? How does it make programming easier?
  2. I'm used to mutable strings, like the ones in C. How am I supposed to program without mutable strings? Are there any best practices?
Mark Amery
  • 143,130
  • 81
  • 406
  • 459
Sergey
  • 47,222
  • 25
  • 87
  • 129
  • 2
    There is a mutable string type, it is called [`bytearray`](http://docs.python.org/library/functions.html#bytearray) – Janne Karila Dec 30 '11 at 18:01
  • 7
    @JanneKarila: The semantics, however, are wildly different. It doesn't, for example, handle Unicode characters, just bytes. It's not a proper string -- with string methods -- it's an adjustable array of bytes. – S.Lott Dec 30 '11 at 21:24
  • @JanneKarila but is it a C-string ? – user13863346 Oct 15 '20 at 06:29

7 Answers7

63

When you receive a string, you'll be sure that it stays the same. Suppose that you'd construct a Foo as below with a string argument, and would then modify the string; then the Foo's name would suddenly change:

class Foo(object):
    def __init__(self, name):
        self.name = name

name = "Hello"
foo = Foo(name)
name[0] = "J"

With mutable strings, you'd have to make copies all the time to prevent bad things from happening.

It also allows the convenience that a single character is no different from a string of length one, so all string operators apply to characters as well.

And lastly, if strings weren't immutable, you couldn't reliably use them as keys in a dict, since their hash value might suddenly change.

As for programming with immutable strings, just get used to treating them the same way you treat numbers: as values, not as objects. Changing the first letter of name would be

name = "J" + name[1:]
Mark Amery
  • 143,130
  • 81
  • 406
  • 459
Fred Foo
  • 355,277
  • 75
  • 744
  • 836
  • 4
    Sooooooo I know this is a bit late, but could you explain what you mean by mutable strings not being reliable in dicts? List are mutable, but can be put in dicts, what would make mutable strings 'unreliable'? – wnnmaw Dec 10 '13 at 04:17
  • 6
    @wnnmaw What larsmans means is that you wouldn't be able to reliably use strings as keys to a dict, since modifying a string would change its hash, which would change the bucket the string would go to. You can see this with lists yourself by trying to use a list as a key to a dictionary (`a = {}; a[[1,2]] = 1` throws a `TypeError`). – Tim Dumol Dec 23 '13 at 17:24
  • But its easy to change strings: `str = list(str); str[0] = "J"; str = ''.join(str)` – WhyAreYouReadingThis Jul 04 '18 at 13:55
  • 5
    I don't get it. What bad consequences could happen if you replace the first letter of name? Isn't it same if I assign a totally new value to `name` in this case? – Nimeshka Srimal Oct 15 '18 at 13:20
17

Immutable strings greatly simplify memory allocation when compared with C strings: you don't guess at a length and over-allocate hoping you over-allocated enough.

They're more secure: you can never have a buffer overrun the way you can in C.

There is only one mutable string use case.

  • replacing a substring or a single character

All other string use cases (concatenation, searching, etc., etc.) the mutability does not matter. In all other cases, mutability does not matter.

If you want to replace a character or a substring in Python, you simply create a new string

x = x[:place] + replacement + x[place+1:]

That's the only code that novel or distinctive.


For reasons I fail to understand, it appears important to add the following.

"There are other ways to avoid a string buffer overflow than immutable strings."

For the purposes of this question (about Python, specifically) immutable strings have a pleasant consequence of no buffer overflows. For other languages, other principles, rules and nuances apply.

S.Lott
  • 384,516
  • 81
  • 508
  • 779
  • 5
    Ruby (as one example) has mutable strings, and it has automatic memory management and can't have buffer overflows. As for replacing substrings being the only use case, what about (in-place-)appending? -1 –  Dec 30 '11 at 13:56
  • There is no "in-place appending". That's just appending. `x = x + y`. Or `x += y`. You can't tell if it was in-place or done with immutable strings. – S.Lott Dec 30 '11 at 17:01
  • @delnan: Ruby? That's not part of this question. – S.Lott Dec 30 '11 at 17:02
  • 1
    You made (before the edit 31 minutes ago) a far more general (and, due to that generality, wrong) statement, to which I provided a counter-example. The part of the question you addressed in that part of your answer ("why make strings immutable?") didn't speak of C. And in-place appending **is** different from concatenating two immutable strings and putting the result back into a variable - the difference is plainly visible to all code that accesses the (old) string (instead of going through the updated variable). –  Dec 30 '11 at 17:39
  • @delnan: Why is your comment about "far more general" question? I'm sorry, but I'm still focused on **this** question which is about C. I suppose that it's fine to make comments that are largely irrelevant to the question, but it seems a bit odd to apply a "far more general" rule to answers. In-place appending in Python is nearly impossible to detect; do you have example code which doesn't rely in `id()` comparisons that would somehow break or otherwise behave badly? The semantics seem indistinguishable. What am I missing? Please be more specific. – S.Lott Dec 30 '11 at 21:23
  • *Your statement* was to general to be true: OP's first asked "why make strings immutable?" with no mention of C and you replied that making strings immutable makes memory management easier and precents buffer overflows. It is true that C has such problems (thus, your edit renders it correct), but a memory-managed language with mutable strings doesn't have these problems either. As for differences with in-place appending: Consider `x = "foo"; y = x; x += '2'` in a Python-like language (i.e. assignment just copies a reference). If strings are immutable, `y == "foo"`. Otherwise, `y == "foo2"`. –  Dec 31 '11 at 11:01
  • @delnan: Clearly, you're not talking about Python. Why not? The question is about Python, isn't it? Why bring up things which are not relevant to the question? What am I missing about your comments? – S.Lott Jan 01 '12 at 14:39
  • 2
    I *am* talking about Python, but to contrast mutable with immutable strings (part of the question and all answers, mind you), I provided an example. This example couldn't have been in Python as it has immutable strings only. In particular, in-place appending (not the contracted form of `s = s + ...` but the operation that modifies the string object) does not exist in Python. That's the point I'm trying to make. Your answer is incomplete regarding operations possible with mutable strings but not possible with immutable strings. –  Jan 01 '12 at 15:25
  • @delnan: So your comments are irrelevant to a question about Python. Got it. Thanks. – S.Lott Jan 02 '12 at 13:40
  • If you consider this question solely about Python as it is (i.e. without mutable strings), then yes. But then half of your (and other's) answer is irrelevant as well. Or so it seems to *me*. Whatever. –  Jan 02 '12 at 13:49
  • @delnan: Since the title of the question has Python in it, and the question is tagged with [Python] I don't see how that can be ignored. But if you want to ignore the context, then please emphasize that in your comments. I found it very hard to understand them because I (foolishly) thought you were considering the title and the context of the question. Clearly, it was my error to think that the title and the tags mattered. – S.Lott Jan 02 '12 at 15:02
  • I have already explained why I believe my comment is as on-topic as your answer. But I'll try again, this time starting from axioms. (1) The question asks "What are the design reasons of making Python strings immutable?", so (2) a comparision of Python's (immutable) strings to mutable strings is in order. (3) We agree on that, your answer does such a comparision. (4) Such a comparision must necessarily consider mutable strings, and thus (5) a language feature that is not included in Python. (6) You do so, choosing C's mutable strings as contrast. **Are these observations correct?** –  Jan 02 '12 at 15:18
  • @delnan: "Are these observations correct". Yes. And your comments are about a bunch of non-Python issues and examples. I get that. And. It confused me to bring up a lot of non-Python stuff. I was clearly in error thinking your comments would focus on Python. I get that, too. I was wrong assuming that the question's title and tags would constrain your comments. Absolutely and completely wrong. You are commenting outside Python. I was wrong to think otherwise. – S.Lott Jan 02 '12 at 17:01
  • Well, I see a pattern emerging here. @delnan's first comment was an opportunity for you to re-write your answer taking into account the point he made and thus improve the answer. For some reason you decided to launch into this aggressive and sarcastic comment thread. I'm not impressed. – David Heffernan Jan 05 '12 at 11:49
  • 1
    I'd continue my argument from the (now confirmed) axioms, but it's getting ridiculous. @DavidHeffernan's comment indicates it has been stated frequently and clearly enough that one person got it. My urge to nitpick has been satisfied. –  Jan 05 '12 at 12:14
  • @DavidHeffernan: So, rewriting a Python-specific answer to a Python-specific question would be the right thing to do? And asking for clarification is "aggressive and sarcastic"? Thanks for clarifying. I thought I was confused by the sudden and unexplained switch in context. – S.Lott Jan 05 '12 at 12:49
  • Clearly you don't know what sarcasm means. – David Heffernan Jan 05 '12 at 12:51
  • 1
    @DavidHeffernan: I apologize for my confusion. I'm totally lost as to what I've done that is so offensive. I asked for clarification and now I have to be labeled as aggressive and sarcastic. Why? What did I do wrong? Am I unable to ask for clarification? If so, how can I understand comments that appear out of context? What did I do to incur such wrath? I apologize to you for being unable to understand the context switch. What am I supposed to **do**? – S.Lott Jan 05 '12 at 12:55
  • 1
    @delnan pointed out that your original answer could be interpreted as implying that immutability was necessary to guarantee that you can never have buffer overruns. I'm sure you didn't mean that. A simple edit would have solved the issue and likely led to upvotes. If you cannot see the sarcasm in some of your comments then I'm not going to stoop to pointing it out. In my view, comments that are as heavily sarcastic as yours detract from what you bring to the site. – David Heffernan Jan 05 '12 at 13:01
  • @DavidHeffernan: "could be interpreted as implying that immutability was necessary"? Are you saying immutability is **not** one of the ways to prevent buffer overruns? I'm surprised by that. And I'm depressed that the the context switch from Python to other non-Python languages is not confusing to you. It sure confused me. I still don't see what's **erroneous**. – S.Lott Jan 05 '12 at 13:05
  • Well, I don't see why immutability particularly helps preventing buffer overruns. The issues seem somewhat orthogonal to me which I think is what @delnan was trying to say. – David Heffernan Jan 05 '12 at 13:08
  • @DavidHeffernan: Immutability prevents buffer overruns because there are exceptions raised on access outside the defined buffer limits. Unlike C, for example, which doesn't test every access against boundaries. "The issues seem somewhat orthogonal to me"? What issues? I only know of one concern with the answer and that is the vague hint that someone might somehow misinterpret it to be the **only** way to prevent buffer overflows (I claim I cannot find in the answer) but which has been asserted repeated in the comments. – S.Lott Jan 06 '12 at 00:07
  • You can raise exceptions on out-of-range access of mutable buffers. – David Heffernan Jan 06 '12 at 07:19
  • 2
    @DavidHeffernan: Things you "could" do don't seem to be relevant to this question. I thought this was a question about immutable Python strings. Again, the context switch has me confused. I guess I should just give up trying to understand the comments. – S.Lott Jan 06 '12 at 10:43
11
  1. Immutable objects are automatically threadsafe.
  2. You will find that using Python strings is trivially easy in comparison to the extreme pain associated with strings in C.
Mark Amery
  • 143,130
  • 81
  • 406
  • 459
David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
8

Immutable strings can be keys in dictionaries and similar data structures, without the need to copy the strings. It is easier to make a mutable wrapper around an immutable string than the other way around.

Rafał Dowgird
  • 43,216
  • 11
  • 77
  • 90
3

Most languages have immutable strings. This includes Java, Python, and C#. Usually when concatenating strings, the language allocates an entirely new string and copies the content of the two strings into the new string.

Immutability does tend to make programming easier. Especially when dealing with a multi-threaded environment.

Jack Edmonds
  • 31,931
  • 18
  • 65
  • 77
2

Immutable strings makes programming much easier, which is why C# and Java use them too.

Had strings been mutable, you would not be able to trust any externally-provided string, since a malicious caller could change it underneath you.
It would also make multi-threading much more difficult.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
1

Immutable strings are much more dangerous than mutable strings in certain contexts. A best practice list should include never temporarily storing passwords or keys as strings in python.

While it is great that immutable strings are safer in string operations and offer other consistency advantages, storing (even temporarily) a password or goodness forbid a key: This puts that value in memory for the life of that program. This may end up inside a core dump file (that is improperly permissioned). If a virtual machine running the program is paused, v-motioned to a different physical machine... this allows the data in memory in this program to leak to people outside the group of users and administrators of the solution.

Due to our massively convenient/complex virtualization stack we've built, you need to do your best to avoid accepting passwords or storing keys in memory. There is precious little information on how to do this, but it's best to follow solutions that use OS native mechanisms designed to perform these operations properly including openssl, ssh, keyring, etc.