py.user.next
А вот так это выглядит во втором
Ваш пример не имеет отношения к обсуждаемому примеру. Я ведь не против типа string. Вопрос что в нем хранить unicode или utf-8. Очевидно что корректное отображение на консоли или в файлах этих данных будет абсолютно идентично.
py.user.next
В третьем питоне я легко могу подстроку взять из определённых символов
Вот в этом и суть. Как вы будете брать подстроку? Зачем ее брать?
Т.е. для unicode мы получаем упрощение взятия подстроки по заданным индексам и принципиально усложняем операции файлового ввода вывода.
Для utf-8 - ввод вывод тривиален. Поиск по индексу именно буквы операция сложности O(N) где N длина строки.
Я утверждаю что взятие по индексу практически никогда не нужно, поэтому логично было хранить данные в виде utf-8 в памяти питона.
py.user.next
Как минимум ты можешь хранить всё в том виде, в котором оно и используется человеком
Человек зырит в файл или на консоль. И ему пофиг unicode это или utf-8, главное чтобы выглядело корректно.
Да бывают горе программисты которые для того чтобы взять циферку из строки пальцем считают по буквам где у нее начало и где конец потом выкусывают и преобразуют в значение. А потом долго удивляются что их программа при любом чихе ломается.
Ну не могу я придумать практических примеров взятия срезов по индексам букв!!! В жизни не было ни разу такого.
Насколько я знаю историю вопроса, выбор в пользу unicode был сделан на основе аргумента что кодировки с переменным количеством байт на букву слишком сложны для реализации. Однако история показала что сейчас они везде используются без проблем. Т.е. логично выкинуть unicode на помойку вместе со всеми encode decode (за исключением случая перекодирования между cp1251 utf-8 koi и т.п.) Ну и в питоне тоже внутреннее представление строк сделать utf-8.