Ситуация: поддержку Python 2.7 прекращают с 2020 года

    Поддержку Python 2.7 прекращают уже первого января. Но многие компании до сих пор не перешли на его обновленную версию. В материале — обсуждаем причины сложившейся ситуации.


    Фото — Jan Kopřiva — 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 изменила требования к разработчикам приложений


    1cloud.ru
    310,15
    IaaS, VPS, VDS, Частное и публичное облако, SSL
    Поделиться публикацией

    Комментарии 30

      +5
      TL;DR: На 2 версии всё ещё много нужных пакетов, а корпорации боятся взорвать прод на регрессе.

      Если честно, слишком много воды и мало конкретики.
        +3
        Позволю себе расширить ваш tl;dr:

        — стата по PyPI
        — кейс Fb
        — вопрос совместимости ОС
        — кейс Red Hat
        — критика новинок в python 3
        — 2to3 и six

        И потом уже (понятно, что проблема общая):
        корпорации боятся взорвать прод на регрессе
        +2
        По примеру PHP у которой поддержка пятой ветки кончилась почти год назад. Малый бизнес даже не чешется — там всегда на ИТ экономят, просят бэкпатчить нужные либы, чтобы работало под семеркой, если вариантов нет. Ынтырпрайз наоборот боится и денег не жалеет, но… он предпочитает огородить сервис файволами, накататить весь стэк с ОС пятилетней давности и радоваться жизни.

        По подсчетам год спустя после EOL еще около 10% народа сидит пятой ветке. Но какой процент использует пятерку по реальным строкам кода, учитывая монструозные проекты для внутреннего корпоративного использования, я даже боюсь представить картину в целом.
          0
          Золотое правило: работает — не трогай.
          Был у меня проект, внутренняя erp, написанный ещё на php4, обновление на 5ку он прошёл и не заметил, а вот на 7ку не одолел. Неделю накликивал сценарии для тестирования, а сам апдейт с фиксами занял меньше 2 дней и это с php 4 на 7.
          +2

          Из личного опыта, мои сервера на Python все живут в микросервисных облачных платформах сейчас.
          В случае с AWS Lambda миграция с Python 2 на 3 прошла хоть и не без приключений, но относительно быстро — разве что средство развёртывания пришлось сменить и доработать.
          А вот с AppEngine SE переход оказался очень болезненным — многие привычные библиотеки и службы от Гугла просто перестали поддерживаться или безбожно глючат и тормозят.


          В итоге миграция Питона с 2 на 3 часто выливается ещё и в дорогостоящее, навязанное извне технологическое перевооружение, причем не приводящее к какому-то заметному улучшению качества жизни пока что.

            0

            Мне одному показалось, что на второй картинке код на PHP?
            Еще и каким-то боком к WordPress, видимо.


            Я не спец по PHP, сам питоном пользуюсь, поэтому несколько обескуражен.

              +3
              Эта ситуация напомнила старый анекдот.
              Партийный лектор выступает в сельском клубе: "… И вот, товарищи, наше советское общество одной ногой прочно стоит в социализме, а другой уверенно шагнуло в коммунизм!"
              Голос из зала: «И долго мы так враскоряку стоять будем?»
                +2

                Лично меня и мою контору 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, двигаться дальше надо.

                  0
                  о необходимости обратной совместимости для языков, о которых заявляют как
                  " промышленные" уже упоминали? проблема вечная, а питон подзабил на это в свое время.

                  и пока разработчики языка питон ( читай еще и котлин, руби, и тд.) не озаботятся серьезно поддержкой этой самой обратной совместимости — статьи наподобии этой будут периодически появляться и говорить об одном и том же: а именно — бизнес не хочет и не будет вкладывать денег в перевод системы на новую версию языка, какой бы она (новая версия языка) не была «вкусной» от синтаксического сахара, красивой от функционального стиля программирования, лаконичной от лямбда выражений и прочего…

                  и надо отдать должное — разработчики питона в данной ситуации повели себя хорошо — держались почти до последнего. столько лет тянуть поддержку 2.7 — честь и хвала.

                  рубисты вон, помнится, как то раз просто плюнули на всех кто не смог перехать на новую версии — причем почти сразу, на горизонте трех или около того лет.

                  а питонисты — молодцы. но увы. неумение в свое время обеспечить обратную совместимость наконец ударило по тем, кто много лет назад поверил молодым питон-программистам с горящими глазами и принял решение разработки больших систем питоне.

                  я к чему? хорошая статья, хорошее напоминание, о необходимости быть осмотрительным, не вестись на «модное в этом сезоне» при выборе средств реализации систем, у которых срок жизни чуть больше пары лет.

                  важно помнить о том, что совсем не лябды, не синтаксический сахар, и не модные фичи и тренды этого сезона делают язык хорошим в промышленной разработке. и даже не LTS.

                  что ответит питон 3 на такого рода запрос? есть ли полная подробная спека эталонного поведения языка? достаточно ли ее для того что бы сделать автоматические тесты, которые позволят проверить насколько «интерпретатор питона от васи пупкина» соответствует эталону? или насколько новая версия интерпретатора соответвует эталону старой?
                    +3
                    Первая версия Python 3 вышла почти 11 лет назад. Python 2.7 вышел годом позднее. Не многие современные решения с LTS предлагают 10-летнюю поддержку. По моему претензии к обратной совместимости и хотелки LTS уже поздновато высказывать. Заявления, подобные вашим, могли быть актуальны лет 6-7 назад, но не сейчас. За 11 лет существования Python 3 можно было сто раз пошевелиться и начать планомерно, а не в авральном режиме, готовить свой код к переходу на новую версию.
                      0
                      я не про авральный режим.
                      я про то, что переписывать большую систему, даже в планомерном режиме — на плохо-совместимую новую версию языка — дело очень дорогое.

                      и отсутствие эксцессов вида «денежные затраты, только потому что создатель языка решил впилить пару новых фишек» — это первейшее требование бизнеса к промышленному языку.

                      если вы пишете «промышленный», сложный код который будет работать ОЧЕНЬ долго — стоимость работ по переводу системы на версию языка, которая потеряла обратную совместимостиь — начинает составлять очень значительную часть бюджета.
                      и платить за это никто не готов.

                      и вопрос не в плановости или авральности. вопрос в том что это дорого. очень дорого.
                      потому, имхо, во многих случаях, говорить о переводе систем на питоне 2.7 на питон 3 — не приходится. никто за это платить не будет.
                      и в 20м году их будут попросту отключать, выводить из эксплуатации и заменять на другие. возможно и вероятно не на питоне написанные.

                      ____________________________________________________
                      ладно. питон 2.7 -> 3 показал как не надо делать обновы, и ладно, дело прошлое опять вспомню про руби тоже пару раз давшему маху… тоже в прошлом.

                      но что же с питоном 3?

                      какие у него есть гарантии или стратегии, которые помогут ему претендовать на роль «промышленного языка для больших систем»? как создатели собираются предотвращать проблемы обратной совместимости и затрат на перевод на новые версии, проблем изменения поведения при смене версий?

                      когда я буду выбирать средства реализации для новой системы — что мне показать в аргументах? или сразу писать, что «ежегодно, на перевод на новые версии питона у вас будет уходить ~20% из бюджета поддержки системы??»

                      20% — цифра, конечно, с потолка, — но она есть, и вопрос в том что делается, что бы ее минимизировать?

                      offtop: можно для сравнения пообсуждать, что можно делать (и что делается) для этого на примере java, но тред же про питон?
                      +1

                      Основная проблема, которой подвергается проект после EOL — отсутствие патчей для закрытия уязвимостей и исправление ошибок, а отнюдь не отсутствие синтаксического сахара и крутых новых фишек.

                        0
                        В этом я с вами полностью согласен.

                        Я как раз и говорю, что новые фичи вобще являются несущественным фактором для промышленного языка. Существенным является что бы поведение системы не менялось при переводе ее на новый интерпретатор/компилятор/платформу, и не требовалось менять код для такого перевода.

                        Более того, я считаю, что проблема EOL средств разработки для больших систем гарантированно наступает. (какой бы не был LTS длительным — он кончится).

                        И _единственный_ путь по предотвращению проблемы окончания EOL — это обеспечение обратной соместимости между версиями языка, когда новая версия пусть и добавляет новвые фичи, но гарантирвоанно не меняет поведение старого кода.

                        Вот я и пытаюсь узнать — что делается создателями питона 3, что бы помочь избежать проблем связанных с EOL?
                          +2

                          Обратную совместимость нельзя поддерживать бесконечно. Также есть хорошие архитектурные решения, а есть не очень. Обратная совместимость подразумевает, что поддерживать и тащить в новую версию придется всё. А это увеличивает время на поддержку, сложность системы и неоднозначность, когда несколько решений, обеспечивающих один и тот же функционал, живут параллельно. Мое мнение — ломать обратную совместимость необходимо для прогресса, лучших решений и эволюции языка. Но переход на новую версию должен быть как можно ещё проще. Иначе получится, как с JavaScript, в котором некоторые неудачные решения живут уже не один десяток лет только потому, что иначе все сломается.

                            0
                            вы меня простите, но вы, имхо, по прежнему мыслите категориями «давайте сделаем наш инструмент красивым».

                            бизнесу глубоко положительно и на «прогресс языка» и на неудачную архитектуру — как минимум, пока код работает и делает то что должен и не требует к себе лишнего внимания. потому, что работающий код — это хорошо вложенные деньги, дающие отдачу и экономию.

                            вы ставите во главу угла некий «проресс», кстати не детализаруя что это конкретно значит, а бизнес задается вопросом: «а сколько денег будет стоить этот прогресс» и «кто конкретно за это будет платить»?

                            мы можем и должны развивать экспериментальные языки для новых изучения новых возможностей, архитектуры, но для долговременных больших, промышленных проектов надо нечто совершенное иное. и экспериментальные языки не должны выбираться для разработки больших систем.

                            — Обратную совместимость поддерживать, имхо, можно, достаточно долго, сильно больше чем любая LTS; хотя и при соблюдении ряда условий:

                            1. во перых требуется автомтический контроль за этой совместимостью (читай автоматические тесты валидности интерпритаторов/компиляторов под каждую версию). иначе как эту совместимость действительтно проверять?

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

                            не к ночи будет сказано, но у джавы и джаваскрипта такие спеки есть.
                            и есть альтернативные реализации, и процессы валидации/тестирования/проверки сторонних интерпритаторов тоже есть. и джава и а 13й версии продолжает поддерживать работоспособность версии 1.

                            у питона есть такое? а когда появится?
                            есть альтернативные реализации, совместимые с исходным стандартом?

                            3. требуется вдумчивое отношение к нововведениям, и аккуратное прописывание стандарта новой версии. не на поводу у модно-хипстеров, а с учетом действительной необходимости. опять же, не к ночи будет упомянута джава. что там с js в этой частию мне сказать сложнее, я не отслеживал развитие js в деталях.

                            — вот я и спрашиваю: питон 3 — это всё еще экспериментальный язык, для небольших систем со сроком жизни полгода-год, «с новыми фичами» и с «правильной по последнему слову архитектурой», которая целенаправленно и осознанно ломает обратную совместимость ради новых фич…

                            или это уже язык, претендуюший на звание «промышленный язык» — язык, в разработку кода на котором бизнес может вкладываться на горизонте более 5-10 лет, не боясь, что в какойто момент, все то, что было создано перестанет работать, потому что версия языка перестанет поддерживаться?

                            это не к рассуждениям плохо-хорошо.

                            это к позиционированию, и осознанию места и ниши языка, границ его применимости, внушения толпам молодых красноглазых неофитов/фанатиков правильного понимания о том, «где это можно применять».

                            мне, например, очень нравится идея когда питон применяют математики для расчетов и скриптования повседневных ad-hoc задач. вплоть до того, что я подумывал ввести скриптование на питоне в одной из систем.
                            допускаю изучение питона как учебного языка (на замену паскалю),

                            но меня, же вот буквально подташнивает от попыток и заявлений неофитов создать на этом языке что-то действительно большое, с претензией на долгосрочность. потому что я раз за разом, не первый год, вижу чем кончаются такого рода попытки, и как быстро проходит мода на «очередной заменитель джавы», (опять, простите, «не к ночи будет сказано»).

                            питон 3 готов стать чем то иным?
                              +1
                              Не прощу) Потому что про красоту я не писал, вы сами это придумали. Писал я про эволюцию. А это совсем другое. Например, изменение существующих решений. Пример я уже привел про строки в юникоде. Если ваш бизнес не готов вложиться в переход на новую версию, можно сидеть на старой, никто ее не ломает, работать она будет, пока ваш проект на ней живёт. Если же вы хотите получать новый функционал в языке, меньше ошибок и уязвимостей в том же интерпретаторе, то бизнес должен понимать, что это не всегда нахаляву дается. Иначе берите JS, на нем сейчас чего только не пишут. Там обратная совместимость практически 100%, со всеми вытекающими.
                                –2
                                про красоту я не писал, вы сами это придумали. Писал я про эволюцию. А это совсем другое. Например, изменение существующих решений. Пример я уже привел про строки в юникоде.
                                как эта «эволюция» помогает бизнесу эффективнее выполнять производственные функции?

                                что, лямбда-выражения, которые даже в джаву воткнули, повысили скорость обработки транзакций? нет.

                                а переход на юникод понизил расход ресурсов? опять же, утрируя — нет.

                                а «про юникод» бизнес вас вообще спросит: а почему вы сразу так не сделали? а когда вы разведете руками — запишет в графе «минусы»: "принимали необдуманные рещения, теперь просят с нас денег на перевод системы на вовую версию питона исправление своих ошибок в прошлом".

                                понимаете? во главе угла не эволюция ))) во главе угла сохранение работоспособности и минимизация расходов.

                                Если ваш бизнес не готов вложиться в переход на новую версию, можно сидеть на старой, никто ее не ломает, работать она будет, пока ваш проект на ней живёт


                                в этой фразе нет проработки рисков.

                                бизнес не может (вернее здравомыслящий бизнес не будет) сидеть на неподдерживаемой версии языка/системы, потому что в этом случае, все риски и ответственность связанные с ошибками в платформе/sdk/языке и убытками в следствии этих убытков — лягут на плечи подразделений этого самого бизнеса. а это никому из здравомыслящих менеджеров не надо — никто не хочет быть «виноватым без вины».

                                потому они будут «страховать свои риски» — если есть деньги, покупая техподдержку и перекладывать таким образом ответсенность за косяки в коде на плечи производителя.

                                но! повторюсь, что переход на новые версии языка, с целью сохранения поддержки — может быть крайне дорогостоящим предприятием в случае поломки совместимости. в итоге, такую постоянную гонку с переходом на новые версии можно похволить себе только для небольших систем.

                                Если же вы хотите получать новый функционал в языке,…
                                вы продолжаете мыслить не теми категориями.
                                «бизнесу» — глубоко все равно какие там функции в языке.
                                … меньше ошибок и уязвимостей в том же интерпретаторе, то бизнес должен понимать, что это не всегда нахаляву дается
                                никто не говорит про халяву. но затраты бывают разные

                                есть одна стоимость техподдержки, она линейна от времени.

                                и есть другая стоимость — стоимость по переработке системы на новую версию платформы/языка. и это требуется выполнить что бы иметь возмодность заплатить за первое. и эта стоимость растет нелинейно от объема кода.

                                а новые фичи языка — бизнусу побоку. не нужно ему это.
                                ему нужны функции в производственной системе.

                                имхо, самый большой риск бизнеса связанный с it: это остаться в ситуации, когда производитель больше не оказывает услуг по техподдержке старых версий (не на кого переложить ответственность), а пересаживать систему на новую версию языка крайне затратно, потому что они вкладывались в разработку системы последние лет 5, и они стала очень большой.

                                и я снова спрашиваю: может ли питон 3 предложить что либо для минимизации таких рисков кроме LTS ( который, как было описано выше — не очень сильно помогает на большом сроке )?
                                  0
                                  Иначе берите JS, на нем сейчас чего только не пишут. Там обратная совместимость практически 100%, со всеми вытекающими.
                                  вообще, js плохо подходит для больших систем, в следствии динамической типизации.

                                  опять же вспомню про создателей node.js, которые (честь и хвала им) осознали это достаточно быстро, и пересаживают всех на typescript. но, имхо, им этого тоже не надолго хватит, потому что «та же многопоточность», от которой никуда не деться, но которую нельзя впилить внятно в это «дитя js». потому js — нет, не подходит для сложных систем.

                                    +2
                                    > в этой фразе нет проработки рисков.

                                    Ну плохой у вас управленческий состав, если вы риски не проработали и взяли питон для разработки системы, не понимая, что придется вкладываться в переход на новую версию. А это стало известно ещё 10 лет назад.
                                    Вы поймите, в опенсорсе никто никому ничего не должен. Хотите поддержку, форкайте питон и пилите свой интерпретор с блэкджэком, но уже за деньги. Питон вам, как бизнесу достался бесплатно, инструменты типа всяких фреймворков — тоже. А тут, видите ли, новую версию выпустили, а старую больше 10 лет не хотят поддерживать, вот негодяи. В опенсорсе любой инструмент может перестать поддерживаться. И если вы, как бизнес, выбрали его, но не заложились в эти риски, ну, плохо значит свою работу сделали.

                                    > вы опять мыслите не теми категориями.

                                    Это у вас почему-то нет связи между новым функционалом, который может принести профит вашему бизнесу. Например, asyncio, может ускорить операции значительно, приложение будет решать больше задач в единицу времени (а может и что-то, что ранее вы вообще не могли реализовать из-за низкой производительности потоков, например). Или тайпинги, которые могут сделать вашу кодовую базу стабильнее за счёт внедрения чекера. Меньше времени на исправление багов из-за неправильных типов — больше времени на разработку новых фичей. Или значительно меньшее потребление памяти при использовании словарей. Например, ваше приложение требовало 10гб оперативы, а в новой версии будет требовать 5гб к примеру. Экономия на железе.

                                    > и самый большой риск бизнеса связанный с ит: это остаться в ситуации, когда производитель больше не оказывает услуг по техподдержке старых

                                    Это опенсорс. Когда вы берете опенсорсное решение, вы должны понимать риски. Если нет, ну решение тут непричем.

                                    > и я снова спрашиваю: может ли питон 3 предложить что либо для минимизации таких рисков кроме LTS

                                    Не знаю) Вы как человек от бизнеса, не проработали этот вопрос, когда решили его использовать?

                                    > вообще, js плохо подходит для больших систем, в следствии динамической типизации.

                                    Внезапно, Питон тоже язык с динамической типизацией, только строгой.
                                      0
                                      Это опенсорс. Когда вы берете опенсорсное решение, вы должны понимать риски. Если нет, ну решение тут непричем.
                                      ну, ну… не смешивайте опенсорс и бесплатность/отсутствиеподдержки.

                                      скажем так, Java — тоже сейчас опенсорс.

                                      но можно заказать официальную коммерческую поддержку. а в связи с обновлениями лицензий оракла — еще, и обязаны, если у вас не openJDK.

                                      Не знаю) Вы как человек от бизнеса, не проработали этот вопрос, когда решили его использовать?
                                      я то вот как раз, (вроде) проработал в своё время, и выбираю как правило совсем не питон. и не советую питон в иных ролях кроме как скриптование мелких одноразовых задач. но некоторые заказчики находятся в таком диком убеждении что на питоне можно всё и вся, и для всего пригодно, так свято верят,… что я подумал — «может я что забыл ?»…

                                      Внезапно, Питон тоже язык с динамической типизацией, только строгой.
                                      всё лучше, чем те безобразия как у js или руби )))

                                      и кажется же, что были разговоры про введение статической типизации?.. писал на питоне совсем давно, еще когда только третий был в самую новинку. подумал, может что изменилось. хотя бы методически — описание, стандарт внятный как у js например может появился… <_<
                                      или может питоновцы что то «действительно новое придумали» в плане как быть с большими задачами и рефакторингом…

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

                                      спасибо за диалог.

                                        0
                                        > я то вот как раз, (вроде) проработал в своё время, и выбираю как правило совсем не питон.

                                        Тогда не понимаю, чего вас так бомбит от этой новости) Если вас бизнес заставляет использовать Питон, «потому что модно», а вы не хотите… Ну тут я вижу 2 варианта: сменить заказчика или объяснить риски и переложить эти риски на бизнес, а не бомбить почем зря. Да, есть такой нюанс про отсутствие полной обратной совместимости в Питон. Надо это учитывать, а не жаловаться на ее отсутствие)

                                        > и кажется же, что были разговоры про введение статической типизации?..

                                        Не было таких разговоров. Реализация статической типизации в Питон потребует не только переписывания всего интерпретатора (я про CPython), но и всех проектов, что на нем написаны. Да и не нужно это никому, это один из плюсов Питона. Хотите статическую типизацию, берите Java, зачем вам Питон в этом случае, мне непонятно.

                                        > или может питоновцы что то «действительно новое придумали» в плане как быть с большими задачами и рефакторингом…

                                        Уже все давно придумано и к Питону не имеет отношения. Это фундаментальные знания, не зависящие от языка. Почитайте «Рефакторинг. Улучшение существующего кода» от Мартина Фаулера.

                                        > как минимум для меня, снова закрыт.

                                        Ну слава богу)

                                        И вам не хворать)
                                      0
                                      > потому что «та же многопоточность», от которой никуда не деться, но которую нельзя впилить внятно в это «дитя js»

                                      Есть горизонтальное масштабирование. Node.js в этом плане хорошо масшабируется в виде отдельных процессов) Я вот знаю компанию израильскую компанию Hola, у которых критичные сервисы на JS и достаточно успешно)
                                +1

                                Кстати, выделение байт в тип, отдельный от строк, а также все строки в юникоде по умолчанию — одно из самых правильных и удачных решений в 3 версии. Сохранив обратную совместимость, этого бы не удалось сделать

                                  0
                                  вдумчивое отношение (см ответ выше) — оно включает в себя и выбор базовых решений. опять же, не к ночи, джава от рождения (кажется) была (почему то?) юникодной ( или если это появилось потом — то, кажется, не поломало обратной совместимости ).

                                  с выделение байта в тип — мне прокомметировать сложнее ( не так хорошо знаю питон) но опять же в джаве вспоминается трюк с boxing-unboxing для простых и объектных типов.

                                  согласен, проще — плюнуть на старый механизм, чем придумать как это должно работать совместно.

                                  но поймите, что именно такое «наплевательство» делает питон не выгодным «для бизнеса» с точки зрения длительных инвестиций и разработки больших систем.

                                  и, увы, имхо, то что вы восхваляете как правильное и хорошее в 3м питоне — это, хотя и действитеьно (верю вам) правильное и хорошее, но это прямое следствие необдуманных решений при создании первоначального стандарта языка; а ситуацию из топика — мы имеем в виду «наплевателского» стиля при введении новых фич. имхо.

                                  хотя, иногда такое наверное и надо делать. если вспомнить преход с Qt3 на Qt4 — это было действительно правильно. троллтечю пока еще были троллтечами, вообще с нуля переписали весь апи, получилось очень стройно, удобно и красиво. но, ВАЖНО, что у систем на базе C++/Qt и срок жизни куда менее чем 5-10 лет. ни о какой долгосрочности или громадности систем речи нет.
                                    0
                                    Не используйте питон) Используйте джаву, там же все изначально хорошо спроектировано. И будет вам счастье)
                            +1
                            Буквально недавно вылез такой баг при переходе на py3: в коде происходил экспорт данных в Excel (неавжно), и в одной колонке строковые значения типа «56_123432_343345» превратились в числовые (56123432343345). Оказалось, в коде выполнялось преобразование в int, и в py2 int(«56_123432_343345») выкидывет исключение, и сохранялся строкой, а в py3 — все ок, int(«56_123432_343345») возвращает 56123432343345.
                              +1

                              Так начиная с Python 3.6. Underscores in Numeric Literals

                                +1
                                Не баг, а фича PEP515
                                  0
                                  www.python.org/dev/peps/pep-0515

                                  Вот буквально на днях удивился увидел в коде, читал
                                    +2

                                    Это не баг языка, это у вас в программе баг. Нельзя так строки в числа приводить. Есть же isdigit

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое