Фото — Jan Kopriva — Unsplash
Не все готовы к новому «питону»
В 2020-м году будет прекращена поддержка версии Python 2.7, и обновления по части безопасности приостановят. Несмотря на то, что об этих планах стало известно еще пять лет назад — в 2014 году Гвидо ван Россум, автор Python, лично призывал разработчиков и компании мигрировать на Python 3 — процесс адаптации новой версии идет медленно.
В начале года около 60% пакетов, скачиваемых из The Python Package Index (PyPI), относились к версии 2.7. К сентябрю эта цифра уменьшилась до 40%, но, скорее всего, она не достигнет нуля до дедлайна.
Что тормозит миграцию
В крупных компаниях внедрение нового фреймворка или переход на обновленную технологию всегда требует существенных ресурсов и времени. В некоторых случаях процесс затягивается на месяцы и даже годы. Это связано с массивной кодовой базой и большим числом зависимостей. В Facebook начали переводить сервисы компании на Python 3 еще в 2014 году. На реализацию этого проекта ушел год — пришлось переписать значительное число библиотек и поправить тысячи регрессий. После этого инженеры компании взялись за Instagram — в этом случае переход занял десять месяцев. У Dropbox — миграция на Python 3 идет уже целых три года.
В некоторых компаниях действуют строгие правила согласования существенных технологических обновлений со службой безопасности. Иногда это подразделение регулирует даже загрузку PIP-пакетов. «Безопасников» беспокоит, что при переходе на Python 3 в сервисах начнут появляться критические уязвимости. Действительно, в таких сферах, как банкинг и здравоохранение, цена ошибки может быть высокой. Так, в прошлом году британский TSB — в процессе внедрения новой IT-системы — столкнулся с багом, который вызвал сбой в работе системы мобильного банкинга. В результате 1,9 млн человек потеряли доступ к своим счетам. Организация до сих пор разбирается с последствиями.
Помимо всего прочего, Python 2 все еще поддерживают ведущие ОС на базе Linux. Например, в RHEL пользователи могут выбрать, с какой версией им работать. Хотя операционная система Red Hat постепенно мигрирует на Python 3, этот процесс идет не так гладко, как того хотелось бы. В процессе регулярно находят баги, в основном связанные с работой указателей. В Debian также остается поддержка Python 2, но переход на обновленную версию уже начался. Он также продвигается медленно — инженеры последовательно тестируют библиотеки на совместимость.
В любом случае, даже после полного перехода на Python 3, многие продолжат работать с предыдущей версией — так как некоторые пакеты будут поддерживать компании и энтузиасты из комьюнити.
Что думает сообщество
Резиденты Hacker News в тематическом треде отмечают, что главная причина медленной миграции — отсутствие (до недавнего времени) какой-либо ощутимой выгоды от этого процесса. В языке не было новых функций, которые могли бы заинтересовать разработчиков и подтолкнуть их к переходу на Python 3. При этом некоторые решения, сделанные авторами языка, наоборот, портили впечатление от программирования на нем. В частности, большую волну недовольства вызвало исключение поддержки байтовых строк и переход на исключительную работу с Unicode. В Stack Overflow также отметили, что в экосистеме Python недоставало встроенных инструментов для автоматизированной трансляции кода с одной версии на другую. Проблему решили с появлением таких утилит, как 2to3 и six.
Фото — Hitesh Choudhary — Unsplash
За последние годы функциональность Python 3 значительно расширилась. Добавили перемножение матриц, модуль asyncio для организации конкурентного программирования, а также аннотации типов переменных, полей класса, аргументов и возвращаемых значений функций. Поддержка Python 3 даже появилась для других популярных библиотек, например scikit-learn для ML. Обновленный набор функций должен убедить компании перейти на следующую версию языка. И хотя число адептов Python 3 в следующем году значительно возрастет, полный переход займет существенное время.
Мы в 1cloud.ru предлагаем услугу DNS-хостинга. Зарегистрированные пользователи получают её бесплатно.
На любые вопросы, связанные с работой сервиса, ответят специалисты из нашего центра компетенции.Дополнительное чтение в блоге 1cloud:
Спасет ли облако ультра-бюджетные смартфоны «Как мы строим IaaS»: материалы о работе 1cloud Досмотр электронных устройств на границе — необходимость или нарушение прав человека? Вот это поворот: почему Apple изменила требования к разработчикам приложенийКомментарии (20)
PerlPower
28.11.2019 20:54+1По примеру PHP у которой поддержка пятой ветки кончилась почти год назад. Малый бизнес даже не чешется — там всегда на ИТ экономят, просят бэкпатчить нужные либы, чтобы работало под семеркой, если вариантов нет. Ынтырпрайз наоборот боится и денег не жалеет, но… он предпочитает огородить сервис файволами, накататить весь стэк с ОС пятилетней давности и радоваться жизни.
По подсчетам год спустя после EOL еще около 10% народа сидит пятой ветке. Но какой процент использует пятерку по реальным строкам кода, учитывая монструозные проекты для внутреннего корпоративного использования, я даже боюсь представить картину в целом.
AmdY
29.11.2019 11:16Золотое правило: работает — не трогай.
Был у меня проект, внутренняя erp, написанный ещё на php4, обновление на 5ку он прошёл и не заметил, а вот на 7ку не одолел. Неделю накликивал сценарии для тестирования, а сам апдейт с фиксами занял меньше 2 дней и это с php 4 на 7.
eugals
28.11.2019 20:58+1Из личного опыта, мои сервера на Python все живут в микросервисных облачных платформах сейчас.
В случае с AWS Lambda миграция с Python 2 на 3 прошла хоть и не без приключений, но относительно быстро — разве что средство развёртывания пришлось сменить и доработать.
А вот с AppEngine SE переход оказался очень болезненным — многие привычные библиотеки и службы от Гугла просто перестали поддерживаться или безбожно глючат и тормозят.
В итоге миграция Питона с 2 на 3 часто выливается ещё и в дорогостоящее, навязанное извне технологическое перевооружение, причем не приводящее к какому-то заметному улучшению качества жизни пока что.
justhabrauser
28.11.2019 21:55Мне одному показалось, что на второй картинке код на PHP?
Еще и каким-то боком к WordPress, видимо.
Я не спец по PHP, сам питоном пользуюсь, поэтому несколько обескуражен.
OldFisher
28.11.2019 23:01+3Эта ситуация напомнила старый анекдот.
Партийный лектор выступает в сельском клубе: "… И вот, товарищи, наше советское общество одной ногой прочно стоит в социализме, а другой уверенно шагнуло в коммунизм!"
Голос из зала: «И долго мы так враскоряку стоять будем?»
onegreyonewhite
29.11.2019 02:24Лично меня и мою контору Django 2.2 вынудила дропнуть Python 2.7. Но пока не дропнули, казалось, что преимуществ особо нет, а поддержки маломальски адекватного Python 3.5 (а лучше 3.6) не было в большинстве дистрибутивов, используемых заказчиками.
Но сократив поддержку до 3.5 и поработав так полгода, хочется подняться уже до >=3.6. Куча костылей просто отсеялось, анотации вдохнули жизнь в IDE, избавились от части кода и его тестов. Теперь облизываемся на f-strings и поддержку async (из коробки). С чем-то пришлось расстаться, но ни разу не пожалели.
Да, наши проекты в среднем 10к строк. Это немного, но и команда у нас не 10к единиц.
Правда всё равно хочется адекватного LTS в языке. Я понимаю тех, кто остаётся на 2.7, потому что ему замены нет, ведь новые версии Python'а не имеют длительной поддержки, но, справедливости ради, не ломают старой функциональности (обычно).
Короче говоря legacy — зло (да, капитан), но хотя нет LTS, двигаться дальше надо.
dplsoft
29.11.2019 03:01о необходимости обратной совместимости для языков, о которых заявляют как
" промышленные" уже упоминали? проблема вечная, а питон подзабил на это в свое время.
и пока разработчики языка питон ( читай еще и котлин, руби, и тд.) не озаботятся серьезно поддержкой этой самой обратной совместимости — статьи наподобии этой будут периодически появляться и говорить об одном и том же: а именно — бизнес не хочет и не будет вкладывать денег в перевод системы на новую версию языка, какой бы она (новая версия языка) не была «вкусной» от синтаксического сахара, красивой от функционального стиля программирования, лаконичной от лямбда выражений и прочего…
и надо отдать должное — разработчики питона в данной ситуации повели себя хорошо — держались почти до последнего. столько лет тянуть поддержку 2.7 — честь и хвала.
рубисты вон, помнится, как то раз просто плюнули на всех кто не смог перехать на новую версии — причем почти сразу, на горизонте трех или около того лет.
а питонисты — молодцы. но увы. неумение в свое время обеспечить обратную совместимость наконец ударило по тем, кто много лет назад поверил молодым питон-программистам с горящими глазами и принял решение разработки больших систем питоне.
я к чему? хорошая статья, хорошее напоминание, о необходимости быть осмотрительным, не вестись на «модное в этом сезоне» при выборе средств реализации систем, у которых срок жизни чуть больше пары лет.
важно помнить о том, что совсем не лябды, не синтаксический сахар, и не модные фичи и тренды этого сезона делают язык хорошим в промышленной разработке. и даже не LTS.
что ответит питон 3 на такого рода запрос? есть ли полная подробная спека эталонного поведения языка? достаточно ли ее для того что бы сделать автоматические тесты, которые позволят проверить насколько «интерпретатор питона от васи пупкина» соответствует эталону? или насколько новая версия интерпретатора соответвует эталону старой?
Cykooz
29.11.2019 17:34+3Первая версия Python 3 вышла почти 11 лет назад. Python 2.7 вышел годом позднее. Не многие современные решения с LTS предлагают 10-летнюю поддержку. По моему претензии к обратной совместимости и хотелки LTS уже поздновато высказывать. Заявления, подобные вашим, могли быть актуальны лет 6-7 назад, но не сейчас. За 11 лет существования Python 3 можно было сто раз пошевелиться и начать планомерно, а не в авральном режиме, готовить свой код к переходу на новую версию.
dplsoft
29.11.2019 20:34-1я не про авральный режим.
я про то, что переписывать большую систему, даже в планомерном режиме — на плохо-совместимую новую версию языка — дело очень дорогое.
и отсутствие эксцессов вида «денежные затраты, только потому что создатель языка решил впилить пару новых фишек» — это первейшее требование бизнеса к промышленному языку.
если вы пишете «промышленный», сложный код который будет работать ОЧЕНЬ долго — стоимость работ по переводу системы на версию языка, которая потеряла обратную совместимостиь — начинает составлять очень значительную часть бюджета.
и платить за это никто не готов.
и вопрос не в плановости или авральности. вопрос в том что это дорого. очень дорого.
потому, имхо, во многих случаях, говорить о переводе систем на питоне 2.7 на питон 3 — не приходится. никто за это платить не будет.
и в 20м году их будут попросту отключать, выводить из эксплуатации и заменять на другие. возможно и вероятно не на питоне написанные.
____________________________________________________
ладно. питон 2.7 -> 3 показал как не надо делать обновы, и ладно, дело прошлое опять вспомню про руби тоже пару раз давшему маху… тоже в прошлом.
но что же с питоном 3?
какие у него есть гарантии или стратегии, которые помогут ему претендовать на роль «промышленного языка для больших систем»? как создатели собираются предотвращать проблемы обратной совместимости и затрат на перевод на новые версии, проблем изменения поведения при смене версий?
когда я буду выбирать средства реализации для новой системы — что мне показать в аргументах? или сразу писать, что «ежегодно, на перевод на новые версии питона у вас будет уходить ~20% из бюджета поддержки системы??»
20% — цифра, конечно, с потолка, — но она есть, и вопрос в том что делается, что бы ее минимизировать?
offtop: можно для сравнения пообсуждать, что можно делать (и что делается) для этого на примере java, но тред же про питон?
pesh1983
29.11.2019 19:23+1Основная проблема, которой подвергается проект после EOL — отсутствие патчей для закрытия уязвимостей и исправление ошибок, а отнюдь не отсутствие синтаксического сахара и крутых новых фишек.
dplsoft
29.11.2019 21:03В этом я с вами полностью согласен.
Я как раз и говорю, что новые фичи вобще являются несущественным фактором для промышленного языка. Существенным является что бы поведение системы не менялось при переводе ее на новый интерпретатор/компилятор/платформу, и не требовалось менять код для такого перевода.
Более того, я считаю, что проблема EOL средств разработки для больших систем гарантированно наступает. (какой бы не был LTS длительным — он кончится).
И _единственный_ путь по предотвращению проблемы окончания EOL — это обеспечение обратной соместимости между версиями языка, когда новая версия пусть и добавляет новвые фичи, но гарантирвоанно не меняет поведение старого кода.
Вот я и пытаюсь узнать — что делается создателями питона 3, что бы помочь избежать проблем связанных с EOL?pesh1983
29.11.2019 22:08+1Обратную совместимость нельзя поддерживать бесконечно. Также есть хорошие архитектурные решения, а есть не очень. Обратная совместимость подразумевает, что поддерживать и тащить в новую версию придется всё. А это увеличивает время на поддержку, сложность системы и неоднозначность, когда несколько решений, обеспечивающих один и тот же функционал, живут параллельно. Мое мнение — ломать обратную совместимость необходимо для прогресса, лучших решений и эволюции языка. Но переход на новую версию должен быть как можно ещё проще. Иначе получится, как с JavaScript, в котором некоторые неудачные решения живут уже не один десяток лет только потому, что иначе все сломается.
pesh1983
29.11.2019 22:11+1Кстати, выделение байт в тип, отдельный от строк, а также все строки в юникоде по умолчанию — одно из самых правильных и удачных решений в 3 версии. Сохранив обратную совместимость, этого бы не удалось сделать
robert_ayrapetyan
29.11.2019 03:37Буквально недавно вылез такой баг при переходе на py3: в коде происходил экспорт данных в Excel (неавжно), и в одной колонке строковые значения типа «56_123432_343345» превратились в числовые (56123432343345). Оказалось, в коде выполнялось преобразование в int, и в py2 int(«56_123432_343345») выкидывет исключение, и сохранялся строкой, а в py3 — все ок, int(«56_123432_343345») возвращает 56123432343345.
qqqoid
29.11.2019 11:38www.python.org/dev/peps/pep-0515
Вот буквально на днях удивился увидел в коде, читал
pesh1983
29.11.2019 19:26+2Это не баг языка, это у вас в программе баг. Нельзя так строки в числа приводить. Есть же isdigit
valsaven
TL;DR: На 2 версии всё ещё много нужных пакетов, а корпорации боятся взорвать прод на регрессе.
Если честно, слишком много воды и мало конкретики.
andrewzhuk
Позволю себе расширить ваш tl;dr:
— стата по PyPI
— кейс Fb
— вопрос совместимости ОС
— кейс Red Hat
— критика новинок в python 3
— 2to3 и six
И потом уже (понятно, что проблема общая):