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

Question

В нашей группе мы в основном занимаемся архитектурой поисковых систем и интеграцией контента, и большая часть этой базы кода находится на Python. Все наши инструменты сборки и зависимости модулей Python находятся в системе контроля версий, поэтому их можно извлечь и загрузить среду для использования независимо от операционной системы / платформы, что похоже на подход, используемый 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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Так что мое предложение будет 2,5.

Answer 5

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

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

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

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

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

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

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

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

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