>[оверквотинг удален]
> предполагается многоязычность? И ведь всё равно будет полно ситуаций, когда о
> понятии "кодировка" нужно помнить. Нет, поймите правильно, это всё очень красиво
> и логично. Но стоило ли конкретно это изменение сопряжённых с ним
> проблем? ИМХО, не стоило совершенно. В Python 2 кухню с кодировками
> нужно было понять ровно один раз, и ни для кого, кроме
> писателей хелловорлдов, это проблемы не составляло, а в итоге разруливанием именно
> этой проблемы сломано, боюсь, не менее 70% того кода, который ломается
> при переходе со второй ветки на третью. То есть отказавшись от
> одного, экстремистского по сути своей, изменения, можно было этак втрое уменьшить
> количество проблем портирования.Частично согласен, но в том смысле, что этот переход был неизбежен, только его надо было сделать мягче. Оставить префикс u (вернутый в 3.3), ввести префикс b, сделать раздельные типы bytes и unicode, и дать аккуратно портироваться на это. И затем делать второй этап, когда, например, list(b'abc') даёт числа, а не символы. Или вообще его не делать так, а ввести отдельные функции.
> А прежняя семантика оператора деления кому мешала? Что противоестественного в том, что
> 2/3 будет 0? Это в большинстве языков так, и ни один
> язык пока именно от этого не умер.
Вот это как раз я считаю правильным изменением, и жаль, что новый вариант не был изначально. А смысл очень прост: когда суть операции принципиально меняется от того, что один из операндов вдруг сменил тип на схожий в пределах совместимого - это недопустимо.
Аналогия для "большинства языков" вроде Си не подходит потому, что в них типы статические и там в разы легче проследить, какие типы в операции; хотя и там такое объединение двух разных операций некорректно.
Если считать нормальным разницу в выполнении деления из-за типов операндов, то следующим придётся признать нормальными, например, шуточки Javascript, где 5-"3"==2, но 5+"3"=="53", и аналогичные автоконверсии Perl/PHP/etc. Питон никогда не позволял такие автоконверсии и игнорирования подачи неправильных данных на вход (как в том же Javascript, где parseInt("08")==0), и это правильно - создаётся значительно меньше скрытых багов в коде.
> Наверное, массовый переход на Python 3 состоится всё равно. Но он
> мог бы быть гораздо легче, если бы в чисто внешнем причёсывании
> языка было допущено чуть меньше радикализма. Вот вполне можно было поломать
> не 70% кода, а 5%, и тогда портирование было бы куда
> как проще.
Тут меня больше всего удивляет, например, игра между range и xrange, items и iteritems... Зачем было убивать старое понимание? Кому оно реально мешало? Зачем эти итераторы во всём?
> И меня удивляет, когда великодушный диктатор говорит, что GIL -- это нормально.
> В итоге вместо многопоточного сервера приходится писать какой-то ужас то на
> greenlets, то на Twisted с обязательной расшивкой обработчиков на куски сопрограмм
> и обёртыванием каждой длительной операции неизвестно во что, и заниматься кучей
> подобных, пусть иногда красивых по идеям и реализации, но лишних в
> контексте прикладной задачи вещей. А если бы там была полноценная многопоточность,
> было бы гораздо проще. Там, где нужна действительно параллельная обработка, предлагается
> ограничиваться техникой fork. Но это же безумие, поскольку безо всякой нужды
> усложняет отладку и архитектуру приложения. Иногда fork -- отличное решение, но
> почему это должно быть единственной возможностью?
Тут хорошо было бы сделать в пределах одного процесса несколько "доменов", каждый со своим GIL и пулом тредов, и выделенными точками обмена. Не между отдельными процессами, как сейчас в multiprocessing. Я согласен, что устранять GIL очень дорого. Но можно и без его устранения достаточно просто решить эти же задачи.
> Словом, при принятии некоторых решений разработчиками языка и CPython был сделан очень
> странный выбор. И этот выбор уже породил проблемы. Надеюсь, всё разрешится
> в ближайшие несколько лет. Но большинства проблем могло бы и не
> быть...
И опять-таки - 5 лет это минимальный срок, чтобы пощупать со всех сторон и принять следующее принципиальное решение. Посмотрим, куда оно пойдёт.
