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

Question

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

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

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

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

-Michael

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

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

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

Таким образом, мое предложение будет 2.5.

Answer 3

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

Doing кодирования изо дня в день я буду смотреть через документацию, и я найду именно модуль или функции, которые я хочу, но тогда это будет иметь мало аннотацию: Новое в версии 2.6

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

Answer 4

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

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

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

Обновление 3.0, подобно тому, что я напоминаю людям. У нас есть бюджет для этого. Мы не будем этого делать в этом году, если Django не перескочит до 3.0. Мы можем сделать это в следующем году.

Answer 5

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

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

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

Так что вы делаете, что вы определяете количество поддерживаемых процессоров, например: x86-32, x86-64, СПАРК

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

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

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

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

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