4

我正在开发一个名为GarlicSim的开源应用程序。

到目前为止，我一直在为 Python 2.6 开发它。它似乎不适用于任何其他版本。

我认为生成支持其他 Python 版本的版本很重要。我想我会为 2.5、3.1 甚至 2.4 制作一个版本。

所以我有几个问题：

  1. 组织我的存储库的文件夹结构以包含这些不同版本的好方法是什么？
  2. 将我在一个代码版本中所做的更改“合并”到其他版本的好方法是什么？我知道如何在我的 SCM（即 git）中进行合并，但这些文件夹都在同一个仓库中，我想在它们之间进行合并。当然可以选择为每个版本创建一个 repo，但我认为这不是一个好主意。

有没有人有什么建议？

4

4 回答 4

3

只有在极少数情况下，您才需要为单独的版本提供单独的分支。你提到上下文管理器，它们很棒，不使用它们会很糟糕，你是对的。但是对于 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。

正如 Paul McGuire 所写，甚至可以在不使用 2to3 的情况下使用相同的代码支持 Python 3 和 Python 2，但如果您想支持除 2.6 和 3.x 之外的任何其他版本，我不建议您这样做。你得到了太多这种丑陋的特殊技巧。在 2.6 中，与 Python 3 有足够的前向兼容性，可以编写看起来不错的代码并支持 Python 2.6 和 3.x，但不支持 Python 2.5 和 3.x。

于 2009-10-10T05:32:09.940 回答
1

如果您的代码没有过度依赖异常处理程序中的运行时性能，您甚至可以在没有单独的 Py3 分支的情况下侥幸逃脱。我已经设法为我的所有 Py2.x 版本保留一个 pyparsing 版本，尽管我不得不坚持使用“最低公分母”方法，这意味着我必须放弃使用生成器表达式等一些构造，并且你的观点，上下文管理器。我使用 dicts 代替集合，并且我的所有生成器表达式都被包装为列表推导，因此它们仍然可以追溯到 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，我发现它非常适合保持源代码目录的同步。

因此，即使我保留了两个版本的代码，其中一些统一技术也可以帮助我将差异降低到绝对不兼容的最小值。

于 2009-10-10T04:55:29.237 回答
1

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

差异不是很大，毕竟如果你必须为 2.4 编写一堆额外的代码来做一些在 2.6 中容易的事情，从长远来看，为 2.5 和 2.6 使用 2.4 版本对你来说工作量会更少.

Python 3 应该有一个不同的分支，你仍然应该尽可能多地保持共同的代码。

于 2009-10-10T03:28:21.757 回答
0

我最终决定为我的项目使用 4 个不同的分支，分别用于 2.4、2.5、2.6 和 3.1。我的主要优先级是 2.6，我不想为了 2.4 牺牲代码的优雅。因此，丑陋的兼容性黑客将出现在较低版本上，而不是较高版本上。

于 2009-10-10T18:57:39.283 回答