https://docs.python.org/2/faq/design.html#why-are-python-strings-immutable

Потому что современные имплементации зачастую умнее тебя.

в старичках C и C++ — можно?

int main(){
  *(char*)"asdf"=0;
  }

$ ./a.out 
Ошибка сегментирования

очему в «современных» языках нельзя обратиться к участку памяти, который мне нравится...

...а в старичках C и C++ — можно? разве потеря прямого контроля над памятью — это не очевидный регресс?

Python

One is performance

Python

perfomance

Python

perfomance

AHAHAHAHAHAHA, OH WOW.

Another advantage 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.

они чо, тупые? модифицируется не literal constant, а переменная.

Короче, проще говоря в контексте Пистона: «Потому что и точка!». Я вот не понимаю, когда они пишут про производительность, то каким образом она просядет, если я например в 10 символьной строке поменяю пару символов по их индексу? (ну типа как в С). Такое ощущение, что изначально поленились сделать нормально, а теперь уже и смысла нет, т.к. тонны кода уже написаны и без этого.

Ты внимательно читал? Ещё погугли по SO свой вопрос, там про это норм разжевано.

В хачкеле дефолтные строки, тип String, тоже определены как список символов ([Char] или как-то так). Но почему-то эти дефолтные строки годны только в хелловорлдах, а на деле используются ByteString. Тож поддались влиянию влиянию новомодных язычков, поди.

Лавры анонiмуса не дают покоя?

сам дурак.

самое забавное, что изменение символа в строке — это O(1). а вот если ради этого заменять её на другую, то это унутре как минимум новый аллок. перфоманс такой перфоманс.

ты действительно не понимаешь, чем переменная отличается от литерала?

ну так-то да. вот в нормальном языке Vala, например, несмотря на наличие современного подсчёта ссылок, всё равно можно взять указатель и делать с ним что угодно. вот это называется гибкость. а выпиливание ради выпиливания, потому что это «несовременно» — самый настоящий регресс.

Иммутабельность чего-угодно — это удобно. Из-за мутабельности списков в том же питоне приходится следить за тем, чтобы случайно не изменить чужой список.

Не регресс, а навязываемый языком стиль программирования. Это как С++, только другая крайность.

Так их проще «шарить», можно использовать ссылку на один и тот же экземпляр и не переживать про CoW. В общих случаях это действительно оптимизация. Хотя и затык в других.

чем переменная отличается от литерала

В питоне понятие «переменная» отличается от такового в языках уровня си.

Когда в питоне пишешь foo = bar, то это не операция над foo, а операция над текущим пространством имён — присвоение в пространстве имён имени foo объекту bar.

почему в «современных» языках программирования нельзя изменять строки

да потому что это не нужно

Иммутабельность это как минимум потокобезопасно, причем без накладных расходов на синхронизацию, которых куда больше, чем при создании нового объекта.

Хорошее время вспомнить про GIL?

GIL никак не поможет если конкретная мутация строки в конкретной программе не атомарна.

Не мысль была типа «Зачем потокобезопасность, если всё равно gil»

а в старичках C и C++ — можно?

А в них они разве есть вообще?

Ты про то что на питоне нет смысла писать многопоточные программы? Есть реализации питона без GIL. Есть greenlets. И если не нагружать питон cpu-intensive work, то и с потоками можно жить.

да потому что это не нужно

Ты просто не осилил ООП

Если нужно поменять пару байт, то это не строки, а массивы байт. Очевидно же.

самое забавное, что изменение символа в строке — это O(1)

А если изменится длина строки?

Ты просто не осилил ООП

Да, я даже не понял что это.

Это уже инициализация массива строкой.

int main(){
  char a[]="asdf";
  char *b=a;
  *b=0;
  }

$ ./a.out
$ 

тот факт, что линкер помещает литералы в read-only секцию не означает, что строки в C немутабельны.

глупость

Глупость - это считать дураками тех, кто знает то что ты не знаешь. И судя по треду, знать не хочешь.

Тихо-тихо. Ещё не хватало тут рассказывать про кодировки и другие языки.

ты про иммутабельность? причина в том, что такие алгоримты обработки таких строк плохо расспараллеливаются.

и кстати, это давным-давно пошло — Objective C современник С++, не говоря уже о лиспах где со строками можно было работать как с интернированными символами (правда добровольно, а не добровольно-принудительно)

В нормальных языках для обмазывания байтами есть байтовые массивы. А строки не меняются, чтобы ты не смог отстрелить себе киль.

самое забавное, что изменение символа в строке — это O(1). а вот если ради этого заменять её на другую, то это унутре как минимум новый аллок. перфоманс такой перфоманс.

Самое забавное, что менять строки не нужно от слова вообще. И твой О(1) - всё еще пустая трата электрического тока.

..а в старичках C и C++ — можно?

Потому что в старичках с и с++ нет строк

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

В ruby 3 хотят запилить иммутабельными. Можешь почитать почему, хотя изначально они меняемые (gsub! например).

https://bugs.ruby-lang.org/issues/11473

В ruby 3 хотят запилить иммутабельными.

То есть хотят вообще сделать только иммутабельными? Или опционально?

All String literals are immutable (frozen) on Ruby 3

All — это круто. Руби значит, выпадает из обоймы Ъ-ООП. Сделали бы опционально, хотя бы, как в Io.

https://bugs.ruby-lang.org/issues/11473
Matz said «All String literals are immutable (frozen) on Ruby 3».
This ticket is place holder to discuss about that.

В тикете обсуждение +/- опциональности, magic comments и других подходов. Так же ссылки на другие обсуждения. Можно вдовль обмазаться доводами за и против. Может на целый пакет хватит для сегодняшней ванны.

Просто String будет реализовано так, запили StringOldGoodDays.

а на деле используются ByteString

Text. ByteString - для работы с бинарными данными.

строки

Потому что встроенные в языки «строки» - это минимум, чтоб былО. Тебе ведь никто не мешает замутить свой собственный строковый тип с мутабельностью и CoW.

что изменение символа в строке — это O(1)
что такое юникод

Лол.

All — это круто. Руби значит, выпадает из обоймы Ъ-ООП. Сделали бы опционально, хотя бы, как в Io.

Ты в курсе, что в JS они тоже, того, иммутабельны.

Ну все, ты окончательно доломал anonimusа. Теперь ЛОР захлебнется в потоке беспощадного тупняка.

самое забавное, что изменение символа в строке — это O(1). а вот если ради этого заменять её на другую, то это унутре как минимум новый аллок. перфоманс такой перфоманс.

google://persistent data structure

если я например в 10 символьной строке поменяю пару символов по их индексу?

Я скажу только одно слово, почему это плохая идея: UTF-8