为不同版本的python维护不同版本的codebase的工作流

我最终决定为我的项目准备4个不同的叉子,分别是2.4、2.5、2.6和3.1。我的首要任务是2.6,我不想为了2.4而牺牲代码的优雅。因此,丑陋的兼容性黑客将是低版本,而不是高版本。

如果您的代码不过分依赖异常处理程序中的运行时性能,那么您甚至可能在没有单独的py3分支的情况下逃脱。虽然我不得不坚持使用“最小公分母”方法,也就是说,我必须放弃使用一些结构,比如生成器表达式和上下文管理器。我使用dict代替set,并且我所有的生成器表达式都被包装成列表理解,所以它们仍然可以回到python 2.3。我在代码的顶部有一个块负责处理一些2vs3问题(由pyparsing用户robert a clark提供):

_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:

到

except exceptionType as varname:

当然,如果您不真正需要异常变量,您只需编写:

except exceptionType:

这对py2或py3有效。但是,如果需要访问异常,仍然可以使用跨版本兼容语法:

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

这有一个很小的运行时惩罚,这使得它在pyparsing的某些地方不可用,所以我仍然需要维护单独的py2和py3版本。对于源合并,我使用 WinMerge ,这对于保持源代码目录同步非常有用。

因此,尽管我保留了两个版本的代码,但其中一些统一技术帮助我将差异保持在绝对不兼容的最小值。

我将尝试维护一个分支来覆盖所有python 2.4-2.6

区别并不是很大,毕竟如果你必须为2.4编写一堆额外的代码来做一些在2.6中容易的事情,那么从长远来看,使用2.5和2.6的2.4版本对你来说就不那么重要了。

python 3应该有一个不同的分支,您仍然应该尽可能多地保持代码的通用性。

只有在极少数情况下,才需要单独的分支来处理不同的版本。你提到上下文管理器,它们很好,不使用它们会很糟糕,你是对的。但是对于Python2.4,您不必使用它们。所以那会很糟糕。因此,如果您想支持Python2.4,就必须编写一个没有上下文管理器的版本。但是,这个版本也可以在Python2.6下工作,因此在Python2.6中使用不同的版本是没有意义的。

至于python 3,有一个单独的分支就有一个解决方案,但通常不是最好的。 对于Python3的支持,有一个称为2to 3的东西可以将Python2代码转换为Python3代码。它并不完美,因此经常需要修改Python2代码来生成漂亮的Python3代码,但是Python2代码有一种改进的趋势。

使用distribute(setuptools的维护分支),您可以在安装期间自动进行此对话。这样,即使对于python 3,也不必有单独的分支。见 http://bitbucket.org/tarek/distribute/src/tip/docs/python3.txt 为了那些文件。

正如paul mcguire所写,甚至可以在不使用2to 3的情况下用相同的代码支持python3和python 2,但是如果你想支持2.6和3.x以外的任何东西,我不建议你这样做。你会得到太多这种丑陋的特殊攻击。对于2.6,它与Python3有足够的前向兼容性,可以编写好看的代码,同时支持Python2.6和3.x,但不支持Python2.5和3.x。