Какую версию Python (2.4, 2.5, 2.6, 3.0) вы стандартизируете для разработки продукта (и почему)?

Question

В нашей группе мы в основном занимаемся архитектурой поисковых систем и интеграцией контента, и большая часть этой базы кода написана на Python.Все наши инструменты сборки и зависимости модулей Python находятся в системе контроля версий, поэтому их можно извлечь и загрузить среду для использования независимо от ОС/платформы, что похоже на подход. виртуальное окружение использует.

В течение многих лет мы поддерживали базу кода, совместимую с Python 2.3, поскольку один из коммерческих продуктов, которые мы используем, зависит от Python 2.3.С годами это вызывало все больше и больше проблем, поскольку новым инструментам и библиотекам требовались более новые версии Python с момента выхода версии 2.3 примерно в 2004 году.

Недавно мы отделили нашу среду сборки от зависимостей от среды коммерческого продукта и можем использовать любую версию Python (или Java), какую захотим.Прошло около месяца с тех пор, как мы стандартизировали Python 2.6 как новейшую версию Python, обратно совместимую с предыдущими версиями.

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

Нам нравятся многие новые функции Python 2.6, особенно улучшенные модули и такие вещи, как декораторы классов, но многие модули, от которых мы зависим, заставляют интерпретатор Python 2.6 выдавать различные предупреждения об устаревании.Еще один интересующий нас инструмент для управления узлами облачного кластера EC2: Руководитель даже не работает корректно с Python 2.6.

Теперь мне интересно, стоит ли нам сейчас стандартизировать Python 2.5 вместо использования Python 2.6 при разработке инструментов производственной среды.Большинство инструментов, которые нам нужны/нужны, похоже, корректно работают с Python 2.5.Мы пытаемся разобраться в этом сейчас, пока не появилось много зависимостей от функций или модулей Python 2.6.

Большое спасибо!

-Майкл

Answer 1

Я бы не стал отказываться от версии 2.6 только из-за предупреждений об устаревании;они исчезнут со временем.(Вы можете использовать -W ignore вариант интерпретатора Python, чтобы предотвратить их распечатку, по крайней мере) Но если модули, которые вам нужно использовать, на самом деле не работают с Python 2.6, это будет законной причиной остаться с 2.5.Python 2.5 сейчас широко используется и, вероятно, будет использоваться еще долгое время (подумайте, как долго существует версия 2.3!), поэтому даже если вы выберете версию 2.5, вам не придется какое-то время обновляться.

Я использую Python 2.5 для всей своей разработки, но только потому, что именно эта версия доступна в репозитории пакетов Gentoo (Linux).Когда сопровождающие Gentoo объявляют Python 2.6 «стабильным»*, я перейду на это.Конечно, это рассуждение не обязательно применимо к вам.

* Python 2.6 на самом деле стабилен, причина, по которой он не объявлен как таковой в Gentoo, заключается в том, что Gentoo полагается на другие программы, которые сами зависят от Python и еще не обновлены для работы с 2.6.Опять же, это рассуждение, вероятно, к вам не относится.

Answer 2

Моя компания стандартизирована в версии 2.5.Как и вы, мы не можем перейти на версию 3.0 по миллиону причин, но мне бы очень хотелось перейти на версию 2.6.

Ежедневно занимаясь программированием, я просматриваю документацию и нахожу именно тот модуль или функцию, которая мне нужна, но тогда там будет небольшая аннотация:Новое в версии 2.6

Я бы посоветовал использовать самую новую версию, и если у вас появляются всплывающие предупреждения об обесценивании (вероятно, их будет очень мало), просто найдите лучший способ сделать это.В целом ваш код будет лучше с версией 2.6.

Answer 3

Для меня наиболее важно придерживаться Python 2.5+, потому что он официально поддерживает ctypes, который изменил многие системы плагинов.

Хотя вы можете найти ctypes для работы с 2.3/2.4, они официально не включены в комплект.

Поэтому я предлагаю 2,5.

Answer 4

На данный момент мы придерживаемся версии 2.5.2.Наш стек технологий основан на Django (но у нас есть еще дюжина мелочей). Поэтому мы остаемся рядом с тем, что они делают.

Нам пришлось вернуться к версии docutils 0.4, чтобы она работала с epydoc 3.0.1.До сих пор это не было большой проблемой, но в какой-то момент это может заставить нас переосмыслить использование эпидока.

Обновление 2.6 является частью нашего плана развития.На данный момент у нас есть бюджет, но нет фиксированного графика.

Я также напоминаю людям об обновлении 3.0.Нам нужно выделить на это бюджет.Мы не сделаем этого в этом году, если Django не перейдет на версию 3.0.Возможно, мы сделаем это в следующем году.

Answer 5

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

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

Вместо выпуска исходного кода используйте двоичные файлы, зависящие от платформы (помимо дистрибутива исходного кода).

Итак, вы определяете количество поддерживаемых процессоров, например:х86-32, х86-64, спарк

Тогда какие операционные системы:Linux, Windows, Солярис, FreeBSD

Для каждой ОС вы поддерживаете несколько основных версий.

Следующим шагом будет предоставление двоичных файлов для всех из них.

Да, действительно, это потребует немалых инвестиций в инфраструктуру и настройки автоматической сборки из ваших репозиториев (они у вас есть?).

Преимущество заключается в том, что вашим пользователям нужно установить только «одну» вещь, и вы можете легко переключать версии или даже смешивать версии.На самом деле при таком подходе вы даже можете использовать разные языки программирования, не слишком влияя на управление выпусками.