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

221

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

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

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

Хэм Вокке
источник
3
Неужели так много новых проектов, начинающих использовать Python 2? Или это просто давно созданные проекты, такие как Django?
Carson63000
3
Можете ли вы привести некоторые из обсуждений / источников?
Майкл Пасха
12
@ Майкл Пасха - он не должен. Просто проверьте тег python на SO; многие люди придерживаются мнения «учиться 2.x, 3.x еще не готов».
Ладья
5
Разве вы не видели Python 3 Стена позора ?
детально
7
@ детально, теперь она называется Стена Супердержавы Python 3
freeforall tousez

Ответы:

249

Обратите внимание, что я больше не обновляю этот ответ. У меня гораздо больше вопросов и ответов по 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

ncoghlan
источник
3
Обновлен на основе прогресса, достигнутого за последние 18 месяцев (и явно отметил тот факт, что 3.1 был первым реальным выпуском версии 3.x из-за ужасающей производительности ввода-вывода в 3.0)
ncoghlan
1
В некоторой степени (то есть мы знали, что это было значительно медленнее, чем подсистема io в 2.6), но влияние на общее удобство использования было намного хуже, чем мы ожидали (наши тесты ввода-вывода заметно улучшились с тех пор, поэтому нет никаких шансов на что-то подобное отправлен сегодня)
ncoghlan
6
Предлагаемые сроки не кажутся такими восторженными в 2015 году: |
Зета
1
То, как я это вижу (и я буду обижен на костре некоторыми за это), заключается в том, что на фронте кодирования Py3 нарушил (и продолжает делать, как это и происходит) дзен Python в точке «прагматизм побеждает чистоту» : Py3 кодируется чисто. Py2 был кодирующим-прагматичным.
Юрген А. Эрхард
2
Py3 по-прежнему прагматичен в отношении кодировок (иначе у нас не было бы суррогатного пейзажа), мы просто сталкиваемся с множеством пользователей * nix, которым не интересно слышать о том, как интерфейсы операционной системы работают на платформах, таких как Windows, .NET и JVM ( в том числе Android). Я написал об этом больше на developerblog.redhat.com/2014/09/09/… Основное влияние оказал фронт «ошибки не должны проходить молча», поскольку мы изменили зависимые от данных ошибки, которые приводили к тому, что mojibake превратился в структурные ошибки типа. жаловаться на смешивание двоичных данных и текстовых данных.
ncoghlan
48

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

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

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

TZHX
источник
2
Проблема с зависимостью не имеет порта также рекурсивна. Что нужно, так это для широко используемых библиотек, у которых мало или вообще нет зависимостей вне stdlib для порта, которые могут затем запустить цепную реакцию.
Тони Мейер
10
Я бы поменял порядок. Многие из нас ходят, ожидая перехода конкретного пакета на 3.
S.Lott
1
@ Тони - вот почему я думаю, что это отличная возможность для 3.0, что Numpy теперь доступна для него. @ S.Lott - Полагаю, это действительно зависит от того, предлагает ли 3 то, что вы хотите. Если честно, я совсем недавно перешел с 2,5 на 2,7 - так что я на самом деле не из тех людей, которые следуют «самым последним и лучшим».
TZHX
1
Однако портирование старого кода с помощью 2to3не так сложно, как некоторые опасаются.
ncoghlan
5
Это не помогает, что почти каждая ОС, которая включает Python в дистрибутив (OSX, Linux и т. Д.), Все еще застряла на какой-то древней версии Python 2. Зачем писать для Python 3, когда никто не может использовать ваш код, не оскорбляя с внутренностями их ОС?
Муравей
28

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

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

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

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

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

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

Kamaal
источник
14

Со времени выхода 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
источник
3
Черт, я все еще пользуюсь Fortran77. :) И большинство реальных «возможностей» из Python 3 были перенесены в версии 2.6 и 2.7, без особых проблем с совместимостью. Единственное, что действительно предлагает Python 3, - это «более чистый» синтаксис.
TZHX
3
Сравнивать Python 3 и Perl 6 неправильно. Python 3 - это инкрементальный переход от Python 2, тогда как Perl 6 - это полностью переработанный дизайн. Perl 5 и Perl 6 являются родственными языками и будут существовать в течение длительного времени. С другой стороны, Python 3 планирует заменить Python 2, а не просто сосуществовать. Это большая разница.
Камал
1
Perl 6 все еще находится в стадии разработки. Да, Rakudo Perl является наиболее близкой реализацией к спецификации Perl 6, но пока не реализует все. Просто пока нет готовой к использованию реализации Perl 6.
Htbaa
1
@Htbaa для многих определений полноты и готовности. Perl 6 завершен и готов к производству. Дело в том, что это может занять некоторое время, чтобы соответствовать полной спецификации, есть аналогичные вещи и с другими языками. Например, GCC даже до недавнего времени не совсем соответствовал всей спецификации C ++. Разработка и реализация языка - очень медленный процесс.
Камал
1
rakudo.org/node/75 Звезда Ракудо была выпущена давно. Вы должны попробовать это.
Камал
11

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

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

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

Sharky
источник
7
Опция «-Q» (от 2.2 до 2.7) может выдавать предупреждения для деления. Кроме того, fixdiv.py использует эти предупреждения для обновления выражений в ваших скриптах.
Eryk Sun
10

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

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

9000
источник
10

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

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

Vartec
источник
Кстати, Django только начал экспериментально поддерживать Python3, в версии 1.5.
9000
1
Django 1.6 теперь официально поддерживает Python 3. Flask также поддерживает его.
chhantyal
8

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

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

Пол Натан
источник
4

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

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

марио
источник
4
Возможно, это было однажды, но «apt-get install python3» и «yum install python3» работали в течение длительного времени. Такие инструменты, как Tox и сервисы, такие как Shining Panda CI, упрощают тестирование на нескольких версиях Python.
ncoghlan
Сейчас многие из этих дистрибутивов устанавливают Python3 по умолчанию, в отличие от многих других языков программирования.
Антти Хаапала