Ожидаемо, в общем-то. И я очень рад, что такое мнение наконец-то звучит в PSF. С одной стороны, Python 3 как язык в целом стройнее и логичнее. Я бы ОЧЕНЬ хотел его использовать в работе, и на старте каждого питоновского проекта делаю небольшой анализ, нельзя ли его сделать на Python 3. Но поскольку обычно оказывается нужна куча сторонних библиотек, выясняется, что несколько из них всё ещё не поддерживают третью ветку. Перепиливать их самим на Python 3 невозможно (объём работ в разы превышает трудоёмкость самого проекта). И приходится благополучно продолжать жизнь на второй ветке, которая наверняка фактически будет поддерживаться ещё долго, даже если на python.org будет официально объявлено об отсутствии поддержки.Вот, по-моему, чуть-чуть бы поменьше радикализма в сломе совместимости -- и было бы всё замечательно. Не "ломай всё, раз уж всё равно решили где-то сломать", а "ломай там, где уж совсем никак, но ломай поменьше". Такой подход упростил бы портирование кода (а ведь именно в портировании кода библиотек вся проблема) в разы.
Вот зачем, спрашивается, было переименовывать unicode в str, а str в новый тип? Понятно, что хотелось поддержки многоязычности по умолчанию безо всяких кодировок. Но ведь именно это сломало невероятное количество кода. А ведь вполне можно было разрулить то же самое более щадящим образом. Кому так уж мешала необходимость поставить буковку u перед константой в кавычках, если предполагается многоязычность? И ведь всё равно будет полно ситуаций, когда о понятии "кодировка" нужно помнить. Нет, поймите правильно, это всё очень красиво и логично. Но стоило ли конкретно это изменение сопряжённых с ним проблем? ИМХО, не стоило совершенно. В Python 2 кухню с кодировками нужно было понять ровно один раз, и ни для кого, кроме писателей хелловорлдов, это проблемы не составляло, а в итоге разруливанием именно этой проблемы сломано, боюсь, не менее 70% того кода, который ломается при переходе со второй ветки на третью. То есть отказавшись от одного, экстремистского по сути своей, изменения, можно было этак втрое уменьшить количество проблем портирования.
А прежняя семантика оператора деления кому мешала? Что противоестественного в том, что 2/3 будет 0? Это в большинстве языков так, и ни один язык пока именно от этого не умер.
Вывод: к сожалению, в Python 3 попало несколько изменений, сделанных в интересах самых малоквалифицированных пользователей ("чайников" и "хелловорлдщиков"), но при этом именно этими изменениями и была сломана большая часть совместимости кода. И эти конкретные изменения, что важно, грубо противоречат интересам тех, кто использует Python профессионально (в частности, разрабатывает и поддерживает сторонние библиотеки). Наверное, массовый переход на Python 3 состоится всё равно. Но он мог бы быть гораздо легче, если бы в чисто внешнем причёсывании языка было допущено чуть меньше радикализма. Вот вполне можно было поломать не 70% кода, а 5%, и тогда портирование было бы куда как проще.
И меня удивляет, когда великодушный диктатор говорит, что GIL -- это нормально. В итоге вместо многопоточного сервера приходится писать какой-то ужас то на greenlets, то на Twisted с обязательной расшивкой обработчиков на куски сопрограмм и обёртыванием каждой длительной операции неизвестно во что, и заниматься кучей подобных, пусть иногда красивых по идеям и реализации, но лишних в контексте прикладной задачи вещей. А если бы там была полноценная многопоточность, было бы гораздо проще. Там, где нужна действительно параллельная обработка, предлагается ограничиваться техникой fork. Но это же безумие, поскольку безо всякой нужды усложняет отладку и архитектуру приложения. Иногда fork -- отличное решение, но почему это должно быть единственной возможностью?
Словом, при принятии некоторых решений разработчиками языка и CPython был сделан очень странный выбор. И этот выбор уже породил проблемы. Надеюсь, всё разрешится в ближайшие несколько лет. Но большинства проблем могло бы и не быть...
