Вы можете положить свои вилы и факелы вниз – Python 3 отлично! Если вы сможете перенести свой проект из Python 2 на Python 3, то все это означает, что вы должны сделать это. Но со всей похвалой Python 3 и все большой Переговоры О том, как мигрировать, мы забываем о огромной части приложений Python 2. Приложения, которые не может быть мигрированным. Или не нужно быть мигрированным. Так что давайте поговорим о тех.
Python 2 конец жизни
Python 3 был выше 10 лет. Начальный EOL (конец жизни) для Python 2 был установлен на 2015 год, но он был продлен до 01.01.2020. Вернувшись в 2013 и 2014 годах, люди не были готовы переехать в Python 3. Python 3.0 был в значительной степени непригодным, Python 3.1 и 3.2 были медленнее, чем Python 2. Но главная проблема заключалась в том, что многие из 3-я партийных библиотек все еще использовали Python 2. Это было не до 2012 года, что половина 200 самых популярных пакетов Python была мигрирована в Python 3 (на основе информации от Python 3 стены позора/сверхспокой ). И к 2018 году все же, только около 95% этих пакетов были мигрированы. И это самые популярные пакеты! Для более неясных, статистика, вероятно, еще хуже. Таким образом, разработчики не были готовы в 2015 году. Таким образом, крайний срок продлен еще на 5 лет. В течение этих 5 лет многое изменилось. Последние версии Python 3 (3.6 и up) удивительны – быстрые, богатые функциями (нравится ли вам оператор Walrus или не 😉), а просто приятно работать с. Большинство пакетов Python были мигрированы в Python 3. А те, которые этого не сделали, наверное не будут. Итак, как в 2019 году все еще есть проекты, которые используют Python 2? Ну, есть несколько причин, о которых я могу думать.
Почему у нас еще есть проекты Python 2?
Стоимость миграции слишком высока с деловой точки зрения. Как разработчики, мы понимаем, что за последние несколько лет каждая строка кода Python 2, которую мы пишем, это техническая задолженность. Но большинство компаний не управляются разработчиками. У всех нас есть менеджеры, которые принимают решения, основанные на том, какое деловое значение приносит каждому проекту компании. И тот факт, что язык программирования будет устареть за несколько месяцев, часто бывает не достаточно хорошей причиной, чтобы проводить время, переписывая все. Миграция из Python 2 в Python 3 дороги Отказ И довольно часто ощущается, что это не принесет никаких денег на компанию. Это не добавит новые функции для вашего продукта и, хотя он принесет некоторые улучшения скорости в ваш проект, если бы это была необработанная скорость, которую вы искали, вы, вероятно, не выбрали бы Python в первую очередь. Я никогда не видел продукта, который имеет “Python 3” как одна из его функций на посадке. Если это не продукт для разработчиков.
Всегда есть новая функция, ожидающая в трубопроводе или на срочном исправке, которое необходимо развернуть. И если вы “Agile” (Потому что теперь все «ый»), и у вас огромное отставание, мигрируя на Python 3, вероятно, где-то внизу его. Если Это было достаточно, чтобы даже попасть в отставание. Если вы небольшой запуск, вам нужно сосредоточиться на добавлении новых функций и улучшения опыта пользователей, а не на написании идеального, самого соврегого кода. У вас нет времени для рефакторинга или перезаписи, который просто работает.
И если вы не маленький старт, но большая корпорация, у вас есть другая проблема. Большой кодовой база наследие Python (и большими я имею в виду, например, 35 000 000 строк кода Python 2 ). И Миграция старого кода может быть страшно . Представьте, что у вас есть код, написанный разработчиком, который давно покинул компанию. Есть мало или нет тестов, и документация очень плохая, часто устарела (если есть какие-либо). Код работает, так что все в порядке. Но ни у кого нет идеи, как это работает. Так что никто не касался его года. Это страшная мысль, что в какой-то момент вам придется переписать его. Так что код остается в Python 2.
Миграция на новую версию языка программирования является аналогичной проблемой рефакторинга. В обоих случаях вам необходимо выделить некоторое время, чтобы переписать существующий код, надеясь, что вы сделаете его лучше в долгосрочной перспективе. Но рефакторинг можно сделать следование правил «Boy Scout», что говорит «Вы всегда должны покинуть место в лучшей форме, чем то, как вы его нашли» Отказ Поэтому, когда вы добавляете функцию на функцию, вы чистите эту функцию немного. Миграция не может быть сделана так. Даже если вы можете начать писать Код Standdling (Код, который будет работать как с Python 2, так и Python 3), вам все равно придется переписать другие части приложения в какой-то момент.
Риски пребывания на Python 2
Давайте быстро продвинуться вперед 2 месяца. Python 2 официально мертв, все готовится к Партия для празднования в Pycon 2020 И вы просто сидите там с вашим производственным кодом, все еще работающим на Python 2. И мышление: “Что самое худшее, что может случиться?”
Вы можете взломать. Ну, вы можете взломать на Python 3 или любой другой язык программирования, но на Python 2 есть больший шанс этого. Python 2 не получит никаких обновлений, и это также включает в себя исправление ошибок . Если есть 0-дневный для Python 2, обнаруженный во 2 января – удачи и повеселитесь исправлять его. Никто из основных разработчиков не собирается его исправить. Но это не тот переводчик Python, который вы должны беспокоиться о. Ваша главная проблема, вероятно, собирается быть пакетами, которые вы используете. Большинство из них уже отказались от своих версий Python 2 и Многие больше будут следовать в январе Отказ Чем больше зависимостей, которые вы используете, тем более вероятно, некоторые из них будут иметь проблемы безопасности.
Даже если не будет никаких проблем безопасности с вашим программным обеспечением, поскольку время идет, он медленно начнет разваливаться. Каждый раз, когда вы обновляете часть вашей системы (и вы обновите их, чтобы оставаться в безопасности), есть вероятность, что некоторые из основных зависимостей не будут довольны новым программным обеспечением. И, возможно, некоторые разработчики удаляют свои пакеты из Pypi, устали от того, что пользователи, открывающие новые проблемы в проекте, что они решили устареть давно. В конце концов, вы будете проводить все больше времени, чтобы пожарные, чтобы поддерживать ваш проект.
Удаление пакетов из Pypi заставляет пользователей злиться
Что вы можете сделать с Python 2 EOL?
Так что же вы можете сделать о Python 2 конце жизни? Если вы можете мигрировать в Python 3, то сделайте это! Долгосрочные выгоды перевешивают стоимость миграции. Но если бы вы могли мигрировать, вы, вероятно, сделаете бы это давно, и вы не будете читать эту статью. Поэтому я предполагаю, что вы ищете другие решения. Вот список решений для проекта Python 2, отсортированного по (мое произвольное чувство), насколько сложно реализовать каждый из них:
Ничего не делать
Вы можете притворяться, что Python 3 никогда не случился и игнорирую всю проблему EOL Python 2. Как я уже упоминал ранее, не обновляя свое программное обеспечение, вы рискуете, что уязвимости безопасности будут проникать (и подкрасться к данным ваших клиентов). Кроме того, некоторые ваши зависимости могут перестать работать в какой-то момент. Но, если только место, где вы используете Python 2, это какой-то внутренний скрипт, который вы работаете на вашем компьютере, и у него нет зависимостей, то Ничего Это совершенно прекрасная вещь, чтобы сделать! Не обновляйте Python 3 только потому, что все говорят вам сделать это (хотя мигрирование такого простого сценария будет довольно быстрым и простым). То же самое, если вы ожидаете, что ваше программное обеспечение станет устаревшим в следующем году (возможно, вы уже работаете над другой версией). Взвесьте плюсы и минусы миграции и решайте для себя.
Заморозить состояние вашего заявления
Это интересное решение для всех видов внутренних инструментов, где вы не обеспокоены безопасностью (по «внутренним» я имею в виду – отключен из Интернета), но если некоторые из зависимостей, вы будете в беде Отказ Зависимости для проектов Python 2 начнут разрываться в следующем году. Люди удаляют свои старые проекты из GitHub или даже Pypi, так как я показал вас выше. Помните, что когда мы все смеялись над JavaScript, когда кто-то удалил библиотеку, которая прокладывает текст влево и вдруг все сборки начали разбиться? Ну, подготовьте к этому, но на этот раз никто не будет заботиться, так как «Вы используете устаревшую версию Python» Отказ
К счастью, у нас есть Докер! Или любой другой инструмент, который позволяет создавать неизменные контейнеры Отказ Написать Dockerfile который использует Python 2 в качестве базового изображения. Добавьте все ваши зависимости и настройте свое приложение в виде документа докера. Нажмите это изображение на публичный или частный репозиторий. И Voilà, у вас есть неизменный контейнер с рабочим приложением! Вы можете поделиться его, повторно использовать, и вам не нужно беспокоиться о том, что некоторые зависимости больше не доступны. Это решает большинство проблем для внутренних инструментов. И вы можете сделать это сейчас, а не в 2020 году, когда ваша заявка уже начнет давать вам проблемы.
Изменить переводчик Python
Когда я пишу “Python 2 EOL”, я имею в виду “cpython 2”. CPYthon является самым популярным переводчиком Python, поэтому для многих людей Питон . Но это не единственный переводчик, который у нас есть. Также есть, например, Pypy, которая является твердой альтернативой CPYthon. И поскольку он на самом деле построен на вершине Python 2, Pypy не планирует обезвредить его в любой момент.
Не думайте о Pypy как «Любопытство» что никто не использует. Pypy очень зрелый, это проходит один и тот же тестовый набор, что и CPYthon (или как кто-то пошутил «Это связано с ошибками, соответствует CPYthon» ), и есть компании, которые использовали его в производстве в течение многих лет. Так что это действительная замена Cpython 2. Если вы ищете на YouTube, вы можете найти некоторые примеры людей, счастья его в производстве – Вот один Отказ
Так почему же все не используют Pypy? Потому что у него есть некоторые ограничения. Если ваш проект сильно зависит от расширений C, то Pypy может не быть хорошим решением для вас. Но если вы переключитесь на Pypy, и все работает нормально – что вам нужно проверить с тестами – тогда ваше приложение может даже работать быстрее, чем раньше. Это хороший побочный эффект, чтобы иметь!
Pypy не ваша единственная альтернатива. Intel также поддерживает собственное распределение Python под названием «Распределение Intel® для Python». Это бесплатное распространение, которое поддерживает версии 2.7 и 3.6 Python. Когда я говорил с одним из людей, вовлеченных в этот проект, они заверили меня, что они также не планируют устанавливать версию 2.7 в ближайшее время.
Коммерческие распределения Python
Наконец, есть коммерческие решения. Одним из них является Red Hat Enterprise Linux (RHEL). Если вы покупаете версию 8, Red Hat предоставят вам поддержку Python 2 до июня 2024 года, поскольку они обеспечивают на их сайте . Это могло бы купить вам еще 4 года исправлений ошибок и обновлений для Python 2 … по цене переключения с свободного и открытого языка программирования исходного кода, чтобы на самом деле платить кого-то, чтобы использовать их распространение Python. Есть также другие коммерческие поставщики (которые вы можете найти в Интернете), который предложит вам уплаченную поддержку для версий Python 2.
Поддерживать свой собственный CPY2ON 2 BULDI
Если вы не хотите платить никому за исправить Python 2, вы можете сделать это собой! Все, что вам нужно сделать, это сделать: вилкий репозиторий Cpython, ждать, пока уязвимостей появляются, исправляют их, компилируйте свою собственную версию Cpython и используете это на ваших производственных серверах. Это точно так же утомительно, как звучит, и это, вероятно, не лучшая идея, если вы не знаете, что вы делаете. Вы не хотите быть тем, кто представляет уязвимости на вашем сервере!
Мигрировать в Python 3
Если для вас не работает ни один из вышеперечисленных вариантов, вы можете в конечном итоге мигрировать на Python 3. Есть 2 распространенных способа, как вы можете сделать это: с страдал код или по Переписывание Python 2 код в Python 3.
Код Standdling
STRADDLING код – это код, который работает как с Python 2, так и 3 одновременно. Звучит как больше работы, как вам нужно поддерживать как основные версии Python, но это облегчает переход – нет внезапного выключателя от Python 2 до Python 3. Вы начинаете, запустив тесты под Python 3 (конечно, большинство из них потерпят неудачу), и вы продолжаете переписать части вашего приложения, пока он не работает под Python 2 и Python 3. Затем вы измените версию Python в производстве и, наконец, вы удалите код Python 2. Самым большим преимуществом этого подхода является то, что вы можете сделать это в итерациях. Вы мигрируете части вашей системы, и вы можете продолжать добавлять новые функции в свой код одновременно, поэтому ваши клиенты будут счастливы.
Переписать Python 2 к Python 3
Другой вариант – перезаписывать части кода Python 2 в Python 3. Это требует меньше работы, так как вам больше не заботится о Python 2. Типичный подход состоит в том, чтобы сохранить версию вашего приложения Python 2 Python 2 и начать работу над версией Python 3 в отдельной ветви Git. Вы продолжаете тестировать новую версию и когда она готова, вы вытащите вилку на код Python 2 и включите версию Python 3. Что страшно, как могут быть вещами, которые вы не тестировали, а затем вернулся к Python 2, будет болезненным.
Кроме того, этот подход означает, что вам нужно прекратить добавлять функции в ваше приложение. В противном случае вы будете делать двойную работу – вам нужно добавить эти функции для версий Python 2 и Python 3 вашего приложения.
Перепишите свое заявление
Последнее и самое сложное решение – переписать ваше приложение с нуля в Python 3 или в любом другом языке программирования, который, по вашему мнению, будет работать лучше. Это требует наибольшего объема работы, и она имеет смысл, если версия Python 2 была просто прототипом. Но это позволяет вам полностью отреставрить ваш проект, так что, возможно, на самом деле будет хорошо работать для вас?
Должен ли я мигрировать или нет?
Как я уже сказал в начале, если вы сможете мигрировать в Python 3, сделайте это. Python 3 быстрее, чем Python 2. Он имеет множество отличных функций, таких как Asyncio, типа подсказки, упорядоченные словари, F-струны или лучшая поддержка Unicode. Большинство пакетов, которые планируют мигрировать, уже сделали это. И те, которые этого не сделали, наверное, не будут мигрировать в любом случае. И, наконец, – вы не будете использовать язык программирования, который больше не поддерживается его создателями!
Если вы хотите узнать больше о том, как подготовиться к процессу миграции, посмотрите Последняя часть моего разговора где я даю несколько идей или читаю Python 3 Porting Book – Это отличное, краткое и свободное руководство по тому, как пережить миграцию. Увидимся на другой стороне Python!
Фото из Ника больше на Бессмысленно
Оригинал: “https://dev.to/switowski/you-don-t-have-to-migrate-to-python-3-1hpl”