Страницы

Поиск по вопросам

пятница, 27 декабря 2019 г.

Зачем использовать Python2 вместо Python3?

#python #python_2x


Почему некоторые продолжают использовать интерпретатор предыдущей версии, почему
он еще не умер и не забыт?

Третья версия ушла далеко вперед (один async и новый GIL чего стоят), многие библиотеки
были портированы (ранее, например, был повод использовать Py2 - OpenCV, но и ее портировали).

Единственный повод - поддержка старых проектов и невозможность переезда, но по-прежнему
есть те, кто стартует новые проекты на Py2. Новые вопросы на StackOverflow появляются.

Зачем, какие очевидные причины?
    


Ответы

Ответ 1



Очевидной причиной является несовместимость большинства старых рабочих тестированных Питон 2 программ с Питон 3. Даже если большинство изменений тривиально (и может быть автоматизированно), переход на Питон 3 требует наличия тестов и времени программистов, трату которого надо обосновать. Питон 2 сам по себе уже хорошим языком является. Питон 3 местами лучше, но для каких-то задач может даже хуже показаться на первый взгляд. Даже если разработчики могут найти время для перехода на новый язык, учитывая что программисты люди любознательные, Питон 3 может конкурировать с переходом и на другие языки такие как Go, OCaml (Питон 3 несовместим, но он "недостаточно несовместим" если что-то новое хочется попробовать). Изначальной адаптации Питона 3 не помогало, то что первые версии (до Питон 3.2-3.3) не были предназначены для широкого использования. Большинство книг/ресурсов в сети использовали Питон 2 синтаксис. Обычно, предустановленная команда python запускает Питон 2 на POSIX системах. Большинство живых популярных библиотек работают как на Питоне 2 так и 3. Существует "длинный хвост" библиотек, которые только на Питоне 2 работают (публичные и внутренние инструменты). Из-за заявленной долгосрочной (на данный момент до 2020) официальной поддержки Питона 2, люди немного теряют оставаясь на Питоне 2 (хотя люди часто недооценивают время жизни программ). Заставлять программистов учить разницу между текстом, представленным в виде Unicode строк и байтами создаёт заметный барьер для смены версий для нового кода. Особенно, если программист работает в окружении где текст в основном представлен в виде байт, закодированных в utf-8, или хуже: семантически текстовые интерфейсы используют исторически байтовые API на POSIX системах, которые допускают произвольные последовательности байтов (имена файлов, параметры командной строки, переменные окружения), что требует таких вещей как surrogateescape, чтобы продолжить с Unicode работать по умолчанию. Уроки Чтобы не повторять ошибок, можно было бы избежать смены основной версии и вводить новые изменения поэтапно (Python 4 в понимании Python 3 не должно быть): не накапливать много несовместимых изменений, которые нужно научиться использовать и искать способ подружить со старым кодом (низкая стоимость перехода) возможно большинство новых фич убрать под from __future__ import division, print_function, unicode_literals, etc, которая включается через несколько выпусков по умолчанию (позволяет тестировать, преобразовывать код по одному модулю за раз) публиковать на PyPI модули, облегчающие переход с версии на версию, например, contextlib2, pathlib2, subprocess32, etc предоставить возможность исполнять старый код на новой версии без изменений (чтобы старые программы поддерживать—это относительно просто, если другие пункты также реализовать) конвертировать новую версию в старую, чтобы новый код в старом окружении исполнять (новые программы можно было бы на новой версии языка писать, а исполнять в старом окружении) (3to2 вместо 2to3—см. futurize и pasturize скрипты) ограничить поддержку старых версий (как сейчас 3.2, 3.3, 3.4, 3.5 поддерживаются) — только одна официальная текущая версия языка (чтобы ненужный выбор не создавать) использование semver для языка может быть вредно по психологическим причинам: вместо 3.0 можно было 2.6 выпустить с меньшим набором новых фич (изменение основной цифры может пугать без оснований) медленно убирать старые особо зловредные фичи — упомянуть в документации лучший путь, но фактически задержать на несколько лет удаление старого кода (адаптация под каждую новую версию в любом случае может требовать работы—так барьер между перехода на каждую версию не слишком высок) В итоге: люди, которые любят новые блестящие штучки, могут их использовать, не ожидая перехода всей кодовой базы на новую версию люди, которым надо чтоб продолжало работать, также довольны—старый код не должен ломаться (за исключением обычного ожидаемого подкручивания гаек при переходе на новую версию) особо консервативные люди продолжают сидеть на Python 2.4, 2.6 новички просто начинают с текущей единственной версии

Ответ 2



Для меня одной из очевидных причин являются всяческие UNIX/Linux дистрибутивы, где по умолчанию стоит Python2 и у львиной доли простых юзеров нет прав, чтобы поставить Python 3 на уровне системы. Следовательно все их наработки не будут правильно (если специально этим не озаботиться) работать у остальных юзеров на Python 2. Вот когда все популярные дистрибутивы будут выходить с Python 3 по-умолчанию, тогда можно будет постепенно начинать забывать про Python 2, IMO...

Ответ 3



python2 и python3 сейчас одинаково популярны, для python2 продолжают писать библиотеки, улучшать. В чём-то синтаксис python2 лучше чем у python3, удобнее. К примеру print по моему удобнее писать без скобок. для python2 есть модули которых не сделали для python3. Тем более python 2.7 у меня стоял с самого начала, многие не хотят отвыкать от python2 синтаксиса - поэтому на нём работают многие Вообщем одновременно востребованы две параллельно развивающиеся версии языка Python — 2 и 3.

Ответ 4



Неочевидная проблема, об которую сам как-то обжегся: даже если библиотекой заявлена поддержка Python 3, еще неизвестно какого она качества. Например, год-два назад сделал попытку перейти на Py3: нужен был Pyserial, так он глючил на элементарных вещах, при том что с Py2 работал без проблем, пришлось вернуться на Py2. Также в комменте годичной давности на Hacker News, говорилось что есть аналогичная проблема с Machine Learning библиотеками: есть поддержка Py3, но они забагованнее и поэтому народ все равно использует Py2. В комменте (март 2016) к статье мейнтейнер библиотек говорит что баги проявляющиеся на Py3 месяцами висят, потому что все на Py2. Оригинал: "A trove classifier says nothing about the quality of running a polyglot library on Python 2 or Python 3. I say this as someone who maintains polyglot libraries where I’ve had Python 3 bugs persist for months, because everyone actually uses Python 2." https://blogs.msdn.microsoft.com/pythonengineering/2016/03/08/python-3-is-winning/

Комментариев нет:

Отправить комментарий