Почему строки и кортежи python становятся неизменными?

Ответ 1

Один - это производительность: зная, что строка неизменна, упрощает выложите его во время строительства - фиксированное и неизменное хранилище требования. Это также одна из причины различия между кортежи и списки. Это также позволяет реализация для безопасного повторного использования строки объекты. Например, CPython использование использует предварительно распределенные объекты для односимвольных строк, и обычно возвращает оригинал строка для строковых операций, которая не изменяет содержимое.

Другим является то, что строки в Python считаются "элементальными", как номера. Никакой объем деятельности не будет измените значение 8 на что-нибудь еще, и в Python, никакой активности изменит строку "восемь" на ничего другого.

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

Ответ 2

Представьте себе язык под названием FakeMutablePython, где вы можете изменять строки, используя назначение списка и такие (например, mystr[0] = 'a')

a = "abc"

Это создает запись в памяти по адресу памяти 0x1, содержащую "abc" , и идентификатор a, указывающий на него.

Теперь, скажем, ты...

b = a

Это создает идентификатор b, а также указывает на тот же адрес памяти 0x1

Теперь, если строка была изменчивой, и вы меняете b:

b[0] = 'z'

Это изменяет первый байт строки, хранящейся с 0x1 до z. Поскольку идентификатор a указывает на это, таким образом, эта строка также будет изменена, поэтому..

print a
print b

.. оба выхода zbc

Это может привести к некоторому действительно странному, неожиданному поведению. Хорошим примером этого могут служить словарные ключи:

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

anotherstring = mykey
anotherstring[0] = 'z'

Теперь в FakeMutablePython все становится довольно странным - у вас изначально есть два ключа в словаре: "abc" и "zbc". Затем вы изменяете строку "abc" (через идентификатор anotherstring) на "zbc", поэтому у dict есть две клавиши: "zbc" и "zbc"...

Одним из решений этой странности будет каждый раз, когда вы назначаете строку идентификатору (или используете его как клавишу dict), он копирует строку с 0x1 до 0x2.

Это предотвращает вышеуказанное, но что, если у вас есть строка, которая требует 200 МБ памяти?

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

Внезапно ваш script занимает 400 МБ памяти? Это не очень хорошо.

Как насчет того, укажем ли мы на тот же адрес памяти, пока мы не изменим его? Копировать при записи. Проблема в том, что это может быть довольно сложно сделать.

Здесь возникает неизменность. Вместо того, чтобы потребовать, чтобы метод .replace() скопировал строку из памяти в новый адрес, затем измените ее и верните. Мы просто делаем все строки неизменяемыми, и, следовательно, функция должна создавать новая строка для возврата. Это объясняет следующий код:

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

И доказывается:

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

(функция id() возвращает адрес памяти объекта)

Ответ 3

Одно большое преимущество сделать их неизменными состоит в том, что они могут использоваться как ключи в словаре. Я уверен, что внутренние структуры данных, используемые словарями, будут полностью запутаны, если бы ключи были изменены.

Ответ 4

Неизменяемые типы концептуально намного проще, чем изменчивые. Например, вам не нужно возиться с конструкторами копирования или констант-правильностью, как на С++. Чем больше типов являются неизменными, тем легче становится язык. Таким образом, самые простые языки - это чистые функциональные, не имеющие глобального состояния (поскольку исчисление лямбда намного проще, чем машины Тьюринга, и столь же мощные), хотя многие люди, похоже, не оценивают это.

Ответ 5

Perl имеет изменяемые строки и, кажется, работает просто отлично. Вышеизложенное похоже на много размахивание руки и рационализацию для произвольного дизайнерского решения.

Мой ответ на вопрос о том, почему Python имеет неизменные строки, потому что создатель Python Гвидо ван Россум хотел этого, и теперь у него есть легионы поклонников, которые защитят это произвольное решение от их умирающего дыхания.

Вы могли бы задать аналогичный вопрос о том, почему Perl не имеет неизменяемых строк, а целая часть людей напишет, насколько ужасно само понятие неизменных строк и почему это самая лучшая идея когда-либо (TM), что Perl не " t их.

Ответ 6

профи: производительность

минус: вы не можете изменять mutables.