А что у нас прямое?

[vitus_wagner]

https://developers.slashdot.org/story/19/10/12/2134246/larry-wall-approves-re-naming-perl-6-to-raku

В отличие от Гвидо, который таки прогнул пользователей Python переползти на Python3, Ларри сдался.
И признал что perl 6 это не perl, а Raku. А perl останется тем, что мы уже лет двадцать знаем как perl5.

Comments

[nasse]

Raku - это в честь японской керамики? Заранее страшно...

[alll]

После истории с эпичной шуткой когдатошнего ведущего разработчика шестого перла там уже ничего не страшно.

[avnik]

Лучше бы оба похоронить

[vlkamov]

> perl 6 это не perl

Я знал, я знал !

[burbilog]

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

[vitus_wagner]

Я тоже не понял. Можно было бы обойтись гораздо меньшей кровью, если бы поддержать для bytes все те же операции, что для str и сохранить объединяющий их тип basestring.

[justy-tylor.livejournal.com]

Вообще не надо было строки корёжить. Второй питон прекрасно перенастраивался на utf-8 внутри, и скорее u""-строки там смотрелись как легаси из середины девяностых (когда считалось, что 16 бит в Unicode хватит всем). А это легаси вдруг взяли и сделали основными строками в Python 3.

[vitus_wagner]

А как с буковками-то работать, если они mb, а не wide? Обрезать строку по n-ной буковке, например. Кстати у всех нормальных людей
wchar_t это не 16 бит, а 32. 16 бит он только в тостерах и кофеварках (в смысле Win32 и Java).

[justy-tylor.livejournal.com]

"По буковкам" и в utf-32 наивно разбирать нельзя, надо учитывать combining characters, control characters, особенности Хангыля и прочее.

Продуктивнее использовать компактный utf-8 (без x4 роста объёма занимаемой памяти из-за "в документе попался модный смайлик"), передавать его по сети как есть (ибо стандарт), а при необходимости на лету конвертировать к utf-16 для вызова легаси API на "кофеварках".

[vitus_wagner]

Combining characters это, конечно, да большая засада юникода. Но вообще-то рост объёма будет отнюдь не такой страшный как вы рассчиываете. В UTF-8 все буквы русского языка (а документы все же из букв преимущественно состоят) занимают по два байта. ТАк что в два раза, а в четыре.

А если еще учесть что даже без учета кодировки символов внутреннее представление документа (например дерево XML DOM) занимает на порядок больше памяти, чем сериализованное, то удвоение места на текстовое представление никто не заметит. Указатели (нынче везде 64-битные) место жрут, а вовсе не буковки.

[justy-tylor.livejournal.com]

Зависит от задач. Годах в 2010-2012 я упихивал в память крупные RDF-датасеты, для чего строки хранились не просто дедуплицированно в utf-8, но и с дальнейшей компактизацией по общим префиксам, указатели даже на x64 занимали меньшую долю в memory footprint.

Моя позиция в том, что задачи делятся на:
1. "Не важно как хранить" (из множества utf-8, utf-16, utf-32).
2. "Не важно как хранить, но должно быть компактно и быстро" (только utf-8).
3. "Нужен произвольный O(1) доступ к _любым_ отдельным code points" (только utf-32).

И последняя группа не только самая малочисленная, но и состоит в основном из решений "на ASCII работало, авось и тут будет". При том, что код вроде "найти точку и заменить расширение файла" в неё не входит, и прекрасно работает на utf-8.