什么版本的Python（2.4,2.5,2.6,3.0）可以标准化生产开发工作（以及为什么）？

在我们的小组中，我们主要进行搜索引擎架构和内容集成工作，其中大部分代码都是Python。我们所有的构建工具和Python模块依赖项都在源代码控制之中，因此可以将它们检出并加载环境以供使用，而与OS /平台无关，有点类似于virtualenv使用的方法。什么版本的Python（2.4,2.5,2.6,3.0）可以标准化生产开发工作（以及为什么）？

多年以来，我们一直在维护与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

来源

2009-05-01 Xavian

好的，谢谢你们，到目前为止所有的回复都非常翔实。 :)我仍然没有决定是否要在2.5版本上实现标准化（我们的系统管理员更喜欢由于软件包管理器中的软件包可用性），但迄今为止的评论让我不再犹豫，只是坚持使用Python 2.6并简单地禁止警告在适当情况下。 – Xavian 2009-05-01 17:12:52

只是一个更新，我们已经在Python 2.6上标准化了大约一年，并且它一直在顺利航行。 :) – Xavian 2010-08-24 13:35:57

我不会因为弃用警告而放弃2.6;那些会随着时间消失。（你可以使用Python解释器的-W ignore选项至少防止它们被打印出来）但是如果你需要使用的模块实际上并不适用于Python 2.6，那么使用2.5就是合理的原因。现在Python 2.5已经被广泛使用，并且很可能会持续很长时间（考虑2.3持续了多长时间！），所以即使你使用2.5，你也不会被迫升级一段时间。

我对我所有的开发工作都使用Python 2.5，但仅仅是因为它恰好在Gentoo（Linux）的软件包存储库中可用的版本。当Gentoo维护者声明Python 2.6“stable”*时，我会切换到这个。当然，这个推理不一定适用于你。

* Python 2.6实际上是稳定的，它在Gentoo中没有声明的原因是Gentoo依赖于其他程序，这些程序本身依赖于Python并且尚未升级到2.6。再次，这个推理可能不适用于你。

来源

2009-05-01 16:41:50

作为一个方面说明：Fedora 11将出货2。6作为默认的Python解释器，我怀疑它会开始推动一些移植工作。 – esm 2009-05-01 21:04:32

对我来说，坚持使用python 2.5+最重要的是因为它正式支持，它改变了很多插件系统。

虽然你可以找到ctypes使用2.3/2.4，但它们并没有正式捆绑。

所以我的建议是2.5。

来源

2009-05-01 16:43:31 Francis

我的公司标准化为2.5。和你一样，我们无法将百万原因切换到3.0，但我非常希望我们能够提高到2.6。

编码做日常我会翻翻文件，我会准确地找到我想要的模块或功能，但随后将有小注解：在2.6版中的新

我会说最新版本，如果你有折旧警告弹出（可能会很少），那么就去找一个更好的方法来做到这一点。总的来说，你的代码在2.6中会更好。

来源

2009-05-01 16:44:25 Robbie

我们现在坚持使用2.5.2。我们的技术堆栈以Django为中心（但我们有十几个其他的软件）。所以我们保持接近他们所做的。

我们不得不回到docutils到0.4，所以它可以与epydoc 3.0.1一起使用。到目前为止，这并不是一个大问题，但它可能会在某种程度上导致我们重新思考使用epydoc。

2.6升级是我们发展计划的一部分。我们有预算，但现在没有固定的时间表。

3.0升级同样是我提醒人们的。我们必须为此预算。除非Django跳到3.0，否则今年我们不会这样做。我们明年可能会这样做。

来源

2009-05-01 16:46:51

我认为最好的解决办法就是放弃对整体一致性的希望，尽管拥有共同的环境是值得追求的。您将永远面临版本问题，例如升级到下一个最佳解释器版本时。

因此，不要在每个问题的基础上处理它，您可以通过仔细查看您的版本管理来解决此问题。

而不是释放源代码，去取决于平台的二进制文件（除源代码分发之外）。

所以，你要做的就是，你定义了一些支持的CPU的，例如： X86-32，X86-64，SPARC

然后操作系统：Linux的中，Windows，Solaris和FreeBSD的

对于每个操作系统，您都支持一些主要版本。

下一步是你为它们提供二进制文件。

确实，这需要相当多的基础设施投资，并从您的存储库设置自动构建（您确实拥有它们？）。

优点是您的用户只需要安装一件东西，并且您可以轻松切换版本或混合版本。其实你甚至可以用这种方法使用不同的编程语言，而不会影响你的发布管理太多。

来源

2009-05-01 17:27:00

什么版本的Python（2.4,2.5,2.6,3.0）可以标准化生产开发工作（以及为什么）？

回答

相关问题