Алекс Гейнор (Alex Gaynor), входящий в совет директоров организации Python Software Foundation, выразил опасение, что после 5 лет существования ветка Python 3 до сих пор не получила должного распространения. Первый стабильный выпуск Python 3.0 был опубликован ещё в декабре 2008 года, но с тех пор интенсивность перевода проектов на Python 3 оставляет желать лучшего.
Например, в каталоге Python Package Index с Python 3 связано всего 2% загрузок пакетов. Более того, почти не создано кода, работающего только с Python 3. Такие проекты как Django, добавившие поддержку Python 3, продолжают вести первичную разработку и тестирование с использованием Python 2, попутно проверяя работоспособность в Python 3 через средства непрерывной интеграции. Ни одна опрошенная крупная компания, развивающая проекты на языке Python, не использует специфичный для Python 3 код и не планирует миграцию кодовой базы на Python 3.

В качестве основной причины низких темпов перехода на Python 3 упоминается продолжение параллельного развития ветки Python 2, что привело к отсутствию стимула перехода на Python 3 - при должной поддержке Python 2 и отсутствии мотивов для срочного перехода на Python 3, разработчики приложений могут бесконечно откладывать миграцию, оставляя данную задачу в качестве низкоприоритетных планов.

В качестве второй причины называется отсутствие у разработчиков интереса к ветке Python 3, которая не содержала кардинальных прорывных улучшений, которые могли бы подтолкнуть людей к внедрению новой ветки. В частности, Python 3 не сдвинулся вперёд в таких востребованных областях, как уход от глобальной блокировки (GIL, Global Interpreter Lock) и заметное повышение производительности. Вместо этого в Python 3 был расширен стандартный набор библиотек и проведена чистка проблемных мест, которые опытные разработчики уже научились обходить по привычке. В итоге, 99% разработчиков не используют новшества Python 3 и прекрасно обходятся без них.

В свою очередь, недостаточный объем внедрений рабочих решений на базе Python 3 приводит к проблемам с полноценным тестированием добавляемых новшеств в реальных проектах, что сказывается на ухудшении качества кодовой базы Python 3.x. В качестве одного из выходов из сложившегося тупика предлагается выпустить ветку Python 2.8, в которую бэкпортировать все новшества из Python 3, в том числе объявить устаревшими возможности, для которых нельзя обеспечить обратную совместимость (например, выводить предупреждение при использовании str + unicode), что подтолкнёт разработчиков к адаптации новых возможностей.

Комментарии

# 31 декабря 2013 01:07:04 | Luca 0 0
Странные ребята. Это все равно, что если бы Microsoft после выпуска .NET 4 стала выпускать новые версии .NET 2.1, NET. 2.2 и тд.

Фактически они 5 (!) лет создавали сами себе проблему и теперь вместо ее решения предлагают полумеру. Когда то D клеймили за то, что была нарушена совместимость кода D1 и D2. Однако в итоге таких проблем как у Питонщиков нет. Хотя да, считаю что Python хороший язык.
# 31 декабря 2013 02:12:28 | Babusha 0 0
Luca, самая удачная стратегия оказалась у Ruby, еще ни разу не сталкивался с проблемами обратной совместимости, хотя плюшки в языке новые появляются каждый год с новой версией. Python оказался очень неудачным во многих отношениях, сам как платформа - отстой, интерпретатор медленный и уродливый, сам по себе синтаксис питона во многом отстает от современных тенденций и возможности метапрограммирования и динамичности примерно на уровне 2005 года, набор библиотек вроде бы и большой, но их преимущество сходит на нет из-за различий 2 и 3 версии. В общем, питон создает гораздо больше проблем, чем их решает. Разработчики убунты быстро это прохавали и отказались его использовать.
# 31 декабря 2013 02:39:31 | Luca 0 0
Babusha, проблема в том, что Ruby для скриптинга приложений используется чуть более чем нигде и вряд ли когда либо будет. Что касается сайтов, то на нем в разы меньше удачных решений, это о чем то говорит...
# 01 января 2014 09:56:27 | nixadmin 0 0
Babusha, Ruby - хороший язык, по мне - он гораздо приятней Пайтона, но, объективности ради, и в нём я сталкивался с неприятными проблемами:

1. Обратная совместимость в некоторых гемах. Например - jira4r, авторы забили на этот гем и на soap4r и они не работают на Ruby > 1.8. Решается либо так, либо установкой гемов jira4r-19, soap4r-ruby1.9 и правкой require в своих скриптах. Тут косяк авторов гемов конечно, но он показывает то, что проблемы обратной совместимости при смене интерпретатора таки могут возникнуть

2. Невозможность использовать некоторые гемы в jruby, например - pg, очень удивило, опечалило. В итоге забил на jruby

3. GIL во MRI. Не недостаток, скорее особенность + мой малый опыт разработки. Матцу треды не особо нужны, а я никак не могу осилить процессы =) Вообщем, добавление тредов в мои говноскрипты не дало прироста производительности и я так и не смог понять, толи виноват GIL, толи система которую я долблю по API не даёт работать в неск. потоков. Попробовать другие интерпретаторы не получилось пока, jruby - см. выше, rubinius - чёт не хочет нормально ставиться через rvm.

4. В 2014 г. стандартная библиотека Руби не полностью поддерживает юникод, приходится использовать сторонние гемы.
2.1.0dev :001 > 'тест'.upcase
=> "тест"
2.1.0dev :002 > require "unicode_utils/upcase"
=> true
2.1.0dev :003 > UnicodeUtils.upcase('тест')
=> "ТЕСТ"

Luca, на Руби есть удачные, поддерживаемые и популярные решения. Как админ - я тащусь от систем управления конфигурациями, типа Puppet и Chef. А мои знакомые тестировщики молятся на RSpec и Cucumber. Что касается веба - смотря с чем сравнивать, если с PHP - Руби действительно не много, если с Пайтоном, то Руби, ИМХО, популярнее за счёт Rails. Кстати, сейчас потихоньку изучаю Рельсы и сравниваю со слизанным с них YII. Что радует - приятная экосистема Руби - для выполнения различных тасок в Руби уже есть rake, а в похапешникам приходится городить свои костыли типа yiic'а, а вменяемого аналого связки Gem's + Bundler я в похапе вообще не видел =)
# 01 января 2014 01:47:42 | Babusha 0 0
Сообщение от nixadmin
Обратная совместимость в некоторых гемах
Так никто не отрицал, что нет проблем с обратной совместимостью. А где их нет? Просто эти проблемы гораздо более гладкие, чем в питоне.
Сообщение от nixadmin
2. Невозможность использовать некоторые гемы в jruby, например - pg, очень удивило, опечалило. В итоге забил на jruby
Ну так pg - это интерфейс для работы с базой данных и является оберткой сишной либы, для другой реализации руби придется, понятное дело, все переделывать.
Сообщение от nixadmin
4. В 2014 г. стандартная библиотека Руби не полностью поддерживает юникод, приходится использовать сторонние гемы.
Ничего страшного, это мелочи, по сравнению со вторым питоном.
# 01 января 2014 06:03:25 | MOP3E 0 0
Сообщение от Babusha
Ничего страшного, это мелочи, по сравнению со вторым питоном.
Ковырял я этот ваш руби во встроенном варианте. И честно, со всей откровенностью, скажу - не мелочи. Потому что русский язык это, билят, именно юникод!
# 01 января 2014 06:26:49 | Linux777 0 0
Сообщение от Luca
Фактически они 5 (!) лет создавали сами себе проблему и теперь вместо ее решения предлагают полумеру. Когда то D клеймили за то, что была нарушена совместимость кода D1 и D2. Однако в итоге таких проблем как у Питонщиков нет. Хотя да, считаю что Python хороший язык.

Ты уверен? Пойми, это плохо, потому что таким образом программы будут работать на других ОС таких как Haiku и другие, а надо чтобы было только на Windows.
# 01 января 2014 11:39:37 | OpenMind4423 0 0
по моему главная проблема в том, что программисты уже привыкли к костылям и недостаткам 2го питона, которых нет на 3м питоне, и им просто не хочется переписывать всё наново, если старая ветка поддерживается. Нужно было просто поддержку убрать, а они затянули.
# 01 января 2014 11:53:18 | Linux777 0 1
OpenMind4423, не то чтобы убрать, но запланировать устаревание и отказ от обновлений...
# 02 января 2014 10:37:25 | Babusha 0 0
Сообщение от MOP3E
Ковырял я этот ваш руби во встроенном варианте. И честно, со всей откровенностью, скажу - не мелочи. Потому что русский язык это, билят, именно юникод!
То, что несколько методов не работает с юникодом, еще не значит, что юникод плохо поддерживается, учитывая то, что в руби поддержка юникода интерпретатором вообще была самая первая из всех динамических языков. И манки-патчингом корявые методы можно прозрачно подменить на рабочие и все будет, как ни в чем не бывало.
# 02 января 2014 05:19:19 | OpenMind4423 0 0
Сообщение от Linux777
не то чтобы убрать, но запланировать устаревание и отказ от обновлений...
ну так, а я о чём? А они взяли 2.7 запилили....
# 02 января 2014 08:28:40 | Vladjmir 0 0
Если всех устраивает старая балалайка, зачем её менять на новую? Старые проги работают и каши не просят. А чтобы перейти на новую балалайку, нужны трудозатраты по миграции, надо ковыряться в старом коде. А многие старые проги уже не поддерживаются. Они просто работают. А на новой балалайке они могут сломаться. Поэтому никто не торопится переходить на новую версию. Даже если бы PSF перестала поддерживать Питон 2, его не перестали бы использовать до тех пор, пока на нём работают старые проекты, в которые уже вложены деньги.
# 03 января 2014 05:39:15 | nixadmin 0 0
Сообщение от Vladjmir
Если всех устраивает старая балалайка, зачем её менять на новую?

Язык должен развиваться, должны фикситься баги и добавляться новые фичи, иначе он станет неконкурентоспособен. Другое дело что пайтоновцы сделали странную вещь, запилили новый, несовместимый Пайтон3, да ещё не заморозили развитие Пайтон2.

В других языках устаревший функционал сначала становиться deprecated, а потом и вовсе выкидывается в новых версиях. Такой подход делает миграцию старых проектов наименее болезненной и постепенной. А подход третьего Пайтона заставляет разработчика, посути, переписать свой софт на новом языке используя новый набор библиотек (а нужных может и не быть).

Я думаю, что Пайтон2 впринципе может сейчас пойти по пути постепенного развития и в итоге смержиться с Пайтон3, иного пути перетаскивания проектов и разрабов на новые технологии я не вижу
# 03 января 2014 05:47:33 | MOP3E 0 0
Сообщение от Babusha
То, что несколько методов не работает с юникодом, еще не значит, что юникод плохо поддерживается, учитывая то, что в руби поддержка юникода интерпретатором вообще была самая первая из всех динамических языков. И манки-патчингом корявые методы можно прозрачно подменить на рабочие и все будет, как ни в чем не бывало.
С Ruby я работал только в игровых студиях RpgMaker. И вот там была проблема с юникодом - при расчёте длины строки русские символы часто определялись как пара английских. Хотя, по идее, RpgMaker японский, так что уж юникод-то он должен поддерживать "искаропки". Чего там патчить и где лично мне неясно.

Сообщение от nixadmin
Я думаю, что Пайтон2 впринципе может сейчас пойти по пути постепенного развития и в итоге смержиться с Пайтон3, иного пути перетаскивания проектов и разрабов на новые технологии я не вижу
А оно надо? Ну, переход на третий питон? В том же дотнете в каждой новой версии добавляются действительно нужные нововведения, которыми хочется пользоваться. А в третьем питоне, по сравнению со вторым, похоже, ничего такого нет.
# 03 января 2014 06:41:16 | nixadmin 0 0
Сообщение от MOP3E
А в третьем питоне, по сравнению со вторым, похоже, ничего такого нет.
На сколько я знаю, третий пайтон работает с юникодом без костылей, в отличии от второго. Но дело даже не в этом. Я думаю, что не рационально одновременно развивать две малосовместимые между собой версии пайтона
# 03 января 2014 02:21:00 | Babusha 0 0
Сообщение от MOP3E
. И вот там была проблема с юникодом - при расчёте длины строки русские символы часто определялись как пара английских.
Я не знаю, что там за корявая версия руби была использована, что с ней сделали и как извратились, но все работает у меня - https://ideone.com/sgFbio
# 03 января 2014 07:54:29 | MOP3E 0 0
Сообщение от Babusha
Я не знаю, что там за корявая версия руби была использована, что с ней сделали и как извратились, но все работает у меня
Там это делалось с целью определения ширины выводимой на экран строки в пикселях. Для этого строка перебиралась по одному символу и для каждого символа вычислялась ширина. Так вот, почему-то русские символы считались за два. Сейчас уже не вспомню, если интересно - поковыряй скрипты у этой игры, я для неё перевод делал и столкнулся с данной проблемой. Причём, в двух разных местах. Ищи камменты с моей фамилией.
edited: MOP3E, 03.01.2014 20:03
# 04 января 2014 11:08:46 | Luca 0 0
Порадовал коммент с ЛОРа:
Python слишком безгеморойный.. неинтересно.. там меньше возможностей запутаться.

к примеру если ты в Рython вызываешь функцию foo(), то ты точно знаешь что вызываешь функцию foo() , а НЕ функцию self.foo(), и НЕ функцию bar_module.foo()

а в Ruby — если ты вызываешь foo() — то это может быть что угодно: или метод класса foo(), или импортированная функция foo() (при чём непонятно из какого модуля), или просто функция foo() определённая локально..

так намного прикольнее, и как-то по-хакерске!!:-)

Сообщение от Linux777
Ты уверен? Пойми, это плохо, потому что таким образом программы будут работать на других ОС таких как Haiku и другие, а надо чтобы было только на Windows.
Плохо это когда вопросы требующие редизайна решают костылями, а ничего плохого в том, чтобы для старого софта ставить старый Питон я не вижу. И да, причем тут кроссплатформенность?
# 04 января 2014 01:22:20 | MOP3E 0 0
Сообщение от Luca
И да, причем тут кроссплатформенность?
Дык, он при слове "кроссплатформенность" теряет разум и превращается в бессмысленно гыгыкающего и пускающего слюни пингвина.

------------------------
ТРИО теплый пол отзыв
Заработок на сокращении ссылок
Earnings on reducing links
Код PHP на HTML сайты

Категория: Другое