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

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

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

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

213 голосов | спросил Ham 31 MarpmThu, 31 Mar 2011 12:29:04 +04002011-03-31T12:29:04+04:0012 2011, 12:29:04

9 ответов


243

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

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

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

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

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

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

В то время как люди typing код Python 3 наиболее часто укушены синтаксическими изменениями, такими как print, которые становятся функцией, что на самом деле не является проблемой для переноса библиотек, поскольку автоматическая < code> 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, предстоящая версия Django 1.5 включает экспериментальную поддержку Python 3, а выпуск 12-разрядной сетевой среды Twisted снижает поддержку Python 2.5, чтобы проложить путь для создания совместимого с Python 3 версия.

В дополнение к прогрессу в совместимых с Python 3 библиотеках и фреймворках популярная реализация интерпретатора PyPy, скомпилированная JIT, активно работает над поддержкой 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» для строковых литералов (на самом деле он do ничего в Python 3 - он только что был восстановлен, чтобы избежать непреднамеренного перехода на Python 3 harder для пользователей, которые уже правильно различали свой текстовый и бинарный литералы в Python 2).

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

Так как многие проекты не правильно оценивают свои метаданные индекса пакета Python, а некоторые проекты с менее активными поддерживателями были разветвлены, чтобы добавить поддержку 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.

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

ответил ncoghlan 31 MarpmThu, 31 Mar 2011 16:44:13 +04002011-03-31T16:44:13+04:0004 2011, 16:44:13
48

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

  • Если он не сломался, не исправляйте его
  • [XYZ library], который нам нужен, не имеет 3.0-порта

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

ответил TZHX 31 MarpmThu, 31 Mar 2011 12:41:30 +04002011-03-31T12:41:30+04:0012 2011, 12:41:30
27

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

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

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

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

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

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

ответил kamaal 31 MarpmThu, 31 Mar 2011 12:58:33 +04002011-03-31T12:58:33+04:0012 2011, 12:58:33
13

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

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

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

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

ответил Steve314 31 MarpmThu, 31 Mar 2011 12:55:46 +04002011-03-31T12:55:46+04:0012 2011, 12:55:46
11

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

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

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

ответил Sharky 2 Maypm12 2012, 15:22:52
10

Python 3 с удовольствием запускает новый проект , если все необходимые вам библиотеки уже перенесены в Py3k.

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

ответил 9000 31 MarpmThu, 31 Mar 2011 16:17:33 +04002011-03-31T16:17:33+04:0004 2011, 16:17:33
10

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

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

ответил vartec 31 MarpmThu, 31 Mar 2011 15:04:51 +04002011-03-31T15:04:51+04:0003 2011, 15:04:51
7

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

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

ответил Paul Nathan 31 MarpmThu, 31 Mar 2011 20:50:44 +04002011-03-31T20:50:44+04:0008 2011, 20:50:44
4

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

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

ответил mario 1 AMpFri, 01 Apr 2011 00:45:46 +040045Friday 2011, 00:45:46

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132