Рабочий процесс для поддержки разных версий кодовой базы для разных версий Python

Отдельные ветки для отдельных версий нужны только в самых редких случаях. Вы упомянули менеджеров контекста, и они великолепны, и было бы хреново их не использовать, и вы правы. Но для Python 2.4 вам не придется их использовать. Так что будет хреново. Поэтому, если вы хотите поддерживать Python 2.4, вам придется написать версию без менеджеров контекста. Но этот будет работать и под Python 2.6, поэтому нет смысла иметь там отдельные версии.

Что касается Python 3, имея отдельную ветку есть решение, но в целом не самое лучшее. Для поддержки Python 3 есть что-то под названием 2to3, которое преобразует ваш код Python 2 в код Python 3. Он не идеален, поэтому довольно часто вам придется модифицировать код Python 2, чтобы сгенерировать хороший код Python 3, но код Python 2 в любом случае имеет тенденцию становиться лучше в результате.

С помощью Distribute (поддерживаемого форка setuptools) вы можете вести этот разговор автоматически во время установки. Таким образом, вам не нужно иметь отдельную ветку даже для Python 3. См. http://bitbucket.org/tarek/distribute/src/tip/docs/python3.txt для документации по этому вопросу.

Как пишет Пол Макгуайр, можно даже поддерживать Python 3 и Python 2 с одним и тем же кодом без использования 2to3, но я бы не рекомендовал это, если вы хотите поддерживать что-то еще, кроме 2.6 и 3.x. Вы получаете слишком много этих уродливых специальных хаков. Версия 2.6 обеспечивает достаточную прямую совместимость с Python 3, чтобы можно было писать прилично выглядящий код и поддерживать как Python 2.6, так и 3.x, но не Python 2.5 и 3.x.

Я бы попытался сохранить одну ветку, чтобы охватить все python 2.4-2.6.

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

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

Если ваш код не слишком зависит от производительности во время выполнения в обработчиках исключений, вы можете даже обойтись без отдельной ветки для Py3. Мне удалось сохранить одну версию pyparsing для всех моих версий Py2.x, хотя мне пришлось придерживаться подхода «наименьшего общего знаменателя», что означает, что я должен отказаться от использования некоторых конструкций, таких как выражения генератора, и ваша точка зрения, менеджеры контекста. Я использую dicts вместо наборов, и все мои генераторные выражения обёрнуты как списки, так что они всё ещё будут работать, начиная с Python 2.3. У меня есть блок в верхней части моего кода, который решает ряд проблем 2 на 3 (внесенный пользователем pyparsing Робертом Кларком):

_PY3K = sys.version_info[0] > 2
if _PY3K:
    _MAX_INT = sys.maxsize
    basestring = str
    unichr = chr
    unicode = str
    _str2dict = set
    alphas = string.ascii_lowercase + string.ascii_uppercase
else:
    _MAX_INT = sys.maxint
    range = xrange
    def _str2dict(strg):
        return dict( [(c,0) for c in strg] )
    alphas = string.lowercase + string.uppercase

Самая большая трудность, с которой я столкнулся, была связана с несовместимым синтаксисом для перехвата исключений, который был представлен в Py3, начиная с

except exceptiontype,varname:

to

except exceptionType as varname:

Конечно, если вам действительно не нужна переменная исключения, вы можете просто написать:

except exceptionType:

и это будет работать на Py2 или Py3. Но если вам нужно получить доступ к исключению, вы все равно можете придумать синтаксис, совместимый с кросс-версиями, например:

except exceptionType:
    exceptionvar = sys.exc_info()[1]

Это имеет незначительный штраф во время выполнения, что делает его непригодным для использования в некоторых местах при pyparsing, поэтому мне все еще приходится поддерживать отдельные версии Py2 и Py3. Для слияния исходного кода я использую утилиту WinMerge, которая, по моему мнению, очень удобна для синхронизации каталогов исходного кода.

Так что, хотя я храню две версии своего кода, некоторые из этих методов унификации помогают мне свести различия к абсолютному минимуму несовместимости.

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