Почему люди не решаются использовать Python 3?

Python 3 был выпущен в декабре 2008 года. С тех пор прошло много времени, но до сих пор многие разработчики не решаются использовать Python 3. Даже популярные фреймворки, такие как Django, пока не совместимы с Python 3, но все еще полагаются на Python 2.

Несомненно, Python 3 имеет некоторые несовместимости с Python 2, и некоторые люди должны полагаться на обратную совместимость. Но разве Python 3 не существует достаточно долго, чтобы большинство проектов могли переключиться или начать с Python 3?

Наличие двух конкурирующих версий имеет так много недостатков; необходимо поддерживать две ветви: путаница для учащихся и так далее. Так почему же в сообществе Python так много колебаний по поводу перехода на Python 3?

Обратите внимание, что я больше не обновляю этот ответ. У меня гораздо больше вопросов и ответов по Python 3 на моем личном сайте по адресу http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html.

Предыдущий ответ:

(Обновление статуса, сентябрь 2012 г.)

Мы (то есть разработчики ядра Python) предсказывали, когда Python 3.0 был выпущен, что для 3.x потребуется около 5 лет, чтобы стать выбором «по умолчанию» для новых проектов серии 2.x. Именно благодаря этому прогнозу запланированный период обслуживания для версии 2.7 такой долгий.

В первоначальном выпуске Python 3.0 также обнаружились некоторые критические проблемы с низкой производительностью ввода-вывода, которые сделали его практически непригодным для использования в большинстве практических целей, поэтому имеет смысл начинать сроки с выпуска Python 3.1 в конце июня 2009 года. Проблемы с производительностью ввода-вывода также являются причиной отсутствия выпусков поддержки 3.0.z: нет веской причины, по которой кто-то захочет придерживаться версии 3.0 вместо обновления до 3.1).

На момент написания статьи (сентябрь 2012 года) это означает, что в настоящее время мы находимся в процессе перехода чуть более 3 лет, и этот прогноз, похоже, все еще идет.

В то время как люди, печатающие код Python 3, чаще всего укушаются синтаксическими изменениями, такими как printпревращение в функцию, на самом деле это не проблема для переноса библиотеки, потому что 2to3инструмент автоматического преобразования справляется с этим довольно счастливо.

Самая большая проблема на практике - это семантическая проблема: Python 3 не позволяет вам играть быстро и свободно с текстовыми кодировками, как это делает Python 2. Это и его самое большое преимущество перед Python 2, но также и величайший барьер для портирования: вы должны исправить проблемы с обработкой Unicode, чтобы заставить порт работать правильно (тогда как в 2.x, большая часть этого кода молча создавала некорректные данные с помощью не входящие в ASCII входные данные, создающие впечатление работы, особенно в средах, где не-ASCII данные встречаются редко).

Даже у стандартной библиотеки в Python 3.0 и 3.1 все еще были проблемы с обработкой Unicode, что затрудняло перенос большого количества библиотек (особенно связанных с веб-сервисами).

3.2 решает многие из этих проблем, обеспечивая гораздо лучшую цель для библиотек и сред, таких как Django. 3.2 также принесла первую рабочую версию wsgiref(основной стандарт, используемый для связи между веб-серверами и веб-приложениями, написанными на Python) для 3.x, что было необходимой предпосылкой для принятия в веб-пространстве.

Основная зависимость , как NumPy и SciPy теперь было перенесена, установка и управление зависимостями инструменты , такие как zc.buildout, pipи virtualenvдоступны для 3.x, релиз Pyramid 1.3 поддерживает Python 3.2, предстоящая Джанго 1,5 релиза включает в себя экспериментальную поддержку Python 3, и выпуска 12,0 Twisted Network Framework отказался от поддержки Python 2.5, чтобы проложить путь для создания Python 3-совместимой версии.

В дополнение к прогрессу в библиотеках и инфраструктурах совместимости с Python 3, популярная JIT-скомпилированная реализация интерпретатора PyPy активно работает над поддержкой Python 3.

Инструменты для управления процессом миграции также заметно улучшились. В дополнение к 2to3инструменту, предоставленному как часть CPython (который сейчас считается наиболее подходящим для одноразовых преобразований приложений, которым не требуется поддерживать поддержку для серии 2.x), существует также python-modernize, который использует 2to3инфраструктуру для таргетинга. (большое) общее подмножество Python 2 и Python 3. Этот инструмент создает единую базу кода, которая будет работать на Python 2.6+ и Python 3.2+ с помощью sixбиблиотеки совместимости. Релиз Python 3.3 также устраняет одну из основных причин «шума» при миграции существующих приложений, поддерживающих Unicode: Python 3.3 снова поддерживает префикс «u» для строковых литералов (на самом деле это не так.что - нибудь в Python 3 - это только что было восстановлено , чтобы избежать случайного внесения перехода на Python 3 труднее для пользователей , которые уже правильно отличившихся их текст и бинарные литералы в Python 2).

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

Так как многие проекты не курируют свои метаданные Python Package Index должным образом, а некоторые проекты с менее активными сопровождающими были разветвлены для добавления поддержки Python 3, чисто автоматические сканеры PyPI по-прежнему дают слишком негативное представление о состоянии библиотеки Python 3 служба поддержки.

Предпочтительной альтернативой для получения информации об уровне поддержки Python 3 в PyPI является http://py3ksupport.appspot.com/

Этот список лично курирует Бретт Кэннон (давний разработчик ядра Python) для учета неверных метаданных проекта, поддержки Python 3, которая есть в инструментах управления исходным кодом, но еще не в официальном выпуске, и проектов, которые имеют более современные ветки или альтернативы, которые поддерживают Python 3. Во многих случаях в библиотеках, которые еще не доступны в Python 3, отсутствуют ключевые зависимости, и / или отсутствие поддержки Python 3 в других проектах уменьшает пользовательский спрос (например, как только базовая структура Django доступна в Python 3, связанные инструменты, такие как South и django-celery, с большей вероятностью добавят поддержку Python 3, а наличие поддержки Python 3 в Pyramid и Django повышает вероятность того, что поддержка Python 3 будет реализована в других инструментах, таких как gevent).

Сайт по адресу http://getpython3.com/ содержит несколько отличных ссылок на книги и другие ресурсы для Python 3, определяет некоторые ключевые библиотеки и платформы, которые уже поддерживают Python 3, а также предоставляет некоторую информацию о том, как разработчики могут обращаться за финансовой помощью к PSF в портировании ключевых проектов на Python 3.

Другим хорошим ресурсом является вики-страница сообщества, посвященная факторам, которые необходимо учитывать при выборе версии Python для нового проекта: http://wiki.python.org/moin/Python2orPython3

Я считаю, что многие колебания происходят от двух вещей:

• Если это не сломано, не исправляйте это
• [XYZ библиотека] нам требуется не имеет 3.0 порта

Существует довольно много различий в поведении основного языка, изложенных в этом документе . Например, что-то столь же простое, как изменение «print» из оператора в функцию, приведет к поломке большого количества кода Python 2.x - и это только самое простое. Они полностью избавились от классов старого стиля в 3.0. На самом деле это совершенно разные языки, поэтому перенос старого кода не так прост, как некоторые могут предположить.

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

Помимо пост-миграции, гарантирующей отсутствие сбоев регрессии и всех этих головных болей неизбежно.

Для новых проектов политика проста и понятна, все начинается с следующих моментов:

1. Есть ли дистрибутив, такой как Ubuntu, поставляющий Python 3 в их установке по умолчанию?
2. Что такое библиотечная экосистема для Python 3.
3. Все ли фреймворки совместимы с Python 3. и т. Д.

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

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

Со времени выхода Python 2.0 популярность Python быстро росла. Было много новых пользователей, которые, естественно, использовали последнюю версию, так как они не зависели от старых версий. Поскольку многие люди приняли 2.0 по умолчанию, было большое давление на разработчиков библиотек и т. Д.

К моменту выпуска Python 3.0 уже существовало огромное количество пользователей, зависящих от Python 2.0, и экспоненциальный рост (сохраняя постоянный коэффициент относительно существующих пользователей), очевидно, не может продолжаться бесконечно.

Лично, новые функции в Python 2 дня казались намного более привлекательными, чем те, что были в Python 3.

Раньше я думал, что Python 3 все равно возьмет на себя управление, но сейчас я не уверен. Но проблема не только в Python. В конце концов, сколько людей честно используют Perl 6? Это было чуть дольше, чем Python 3, IIRC.

Большая задержка для шоу, которая, я думаю, не может быть решена с помощью автоматического перевода, это целочисленное деление. У меня есть научные коды, которые основаны на x / 2, дающем x округленным вниз (когда x - целое число).

Python 3 не сделал бы этого, но дал бы ответ .5 (для нечетного x).
Я не могу просто заменить все / в моем коде на //, потому что иногда я делаю операции с плавающей точкой, и поэтому хочу поведение с плавающей точкой.

Итак, чтобы портировать на python 3, мне придется пройтись по десяткам тысяч строк кода, проверить каждую / и посмотреть, смогу ли я выяснить, должен ли он быть / или //.

Python 3 хорош для начала нового проекта, если все необходимые библиотеки уже портированы на Py3k.

Если это не вариант, использование Python 2.7 является лучшим из двух миров: у вас есть большинство библиотек, созданных для Python 2.x, и вы можете постепенно изменить свой код на Py3k-совместимый, так что миграция будет легкой, когда вы решите Это. Список полезностей синтаксиса из Py3k, который у вас уже есть в 2.7, довольно длинный, просто не забудьте импортировать из него __future__. Моими любимыми являются Unicode по умолчанию, и деление всегда производит float.

С точки зрения веб-сервисов: ни одна из основных серверных платформ, ни веб-каркасы не поддерживают Python3.

Обновление: Очевидно, что это имело место в начале 2011 года, а сейчас (в конце 2013 года) большинство основных фреймворков работают с Python3. Однако некоторые все еще не совместимы. Важным примером будет Twisted, где он все еще находится в стадии разработки .

Я не видел убедительных причин использовать P3K, если вы не выполняете тяжелую работу на i18n. В своих набегах я обнаружил, что повсеместный Юникод является барьером для моей (ASCII) работы и обязательных генераторов для засорения моего кода.

Через несколько лет 3 представит более привлекательную среду, но не сегодня.

Распределения не делают Python3 доступным. Есть несколько периферийных дистрибутивов, которые уже переходят с Python2. Но обычные варианты Linux, такие как Debian, Ubuntu и т. Д., Этого не делают. Это главная причина, по которой я, как автор приложения, не могу этого сделать.

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