52

考虑到 Python 3 即将问世，我确信这是大多数 Python 开发人员心中的一个主题。一些问题可以让我们朝着正确的方向前进：

  1. 您是否将同时维护一个 python 2 和 python 3 版本，或者一旦完成，您将只拥有一个 python 3 版本？

    • 您是否已经开始或计划很快开始？还是你打算等到最终版本出来再全面展开？
4

7 回答 7

90

这是 Twisted 的总体计划。我本来打算在博客上写这个，但后来我想：既然我能得到积分，为什么还要写博客呢？

  1. 等到有人关心。

    目前，没有人拥有 Python 3。在至少有一个实际用户站出来说“我需要 Python 3.0 支持”之前，我们不会花费大量精力，并且除了以下事实之外还有充分的理由3.0 看起来很闪亮。

  2. 等到我们的依赖项迁移完毕。

    像 Twisted 这样的大型系统有许多依赖项。首先，我们的包括：

    其中一些项目有自己的依赖数组，所以我们也必须等待这些。

  3. 等到有人足够关心来帮助。

    慈善地，有 5 个人在 Twisted 上工作——我说“慈善地”是因为我也算在内，而且我已经好几个月没有承诺了。我们现在有1000 多张开放票，如果能真正修复其中的一些——修复错误、添加功能，并通常让 Twisted 本身成为一个更好的产品——然后花时间将其移植到实质性的新版本的语言。

    这可能包括赞助商足够关心我们来支付费用，但我希望会有大量关心 3.0 支持并希望帮助推动社区向前发展的志愿者涌入。

  4. 听从圭多的建议。

    这意味着我们不会不兼容地更改我们的 API，并且我们将遵循Guido 去年发布的过渡性开发指南。首先是进行单元测试，并在 Twisted 代码库上运行2to3 转换工具。

  5. 报告针对 2to3 工具的错误和文件补丁。

    当我们到达实际使用它的地步时，我预计2to3将来运行会出现很多问题。现在在 Twisted 上运行它需要很长时间，而且（上次我检查过，那是很久以前的事了）无法解析 Twisted 存储库中的一些文件，因此结果输出不会导入。我认为必须有大量来自小型项目的成功案例，并且在该工具真正为我们工作之前进行大量的锤击。

    但是，Python 开发团队在响应我们的错误报告方面非常有帮助，并且对这些问题的早期响应令人鼓舞，因此我希望所有这些问题都能及时得到修复。

  6. 保持 2.x 兼容性数年。

    目前，Twisted 支持 python 2.3 到 2.5。目前，我们正在努力支持 2.6（我们显然必须在 3.0 之前完成！）。我们的计划是根据长期支持的Ubuntu版本修改我们支持的 Python 版本- 包括 Python 2.5 在内的 8.04 版将支持到 2013 年。根据 Guido 的建议，我们需要放弃对 2.5 的支持支持 3.0，但我希望我们能找到解决方法（我们在版本兼容性黑客方面很有创意）。

    因此，我们计划至少在 2013 年之前支持 Python 2.5。两年后，Ubuntu 将发布另一个长期支持的 Ubuntu 版本：如果它们仍然存在并按计划进行，那将是 10.04。我个人猜测这将与 Python 2.x，也许是 python 2.8 一起提供/usr/bin/python，因为有大量的 Python 软件与发行版一起打包，并且需要很长时间才能全部更新。因此，从那时起五年后，即 2015 年，我们可以开始考虑放弃 2.x 支持。

    在此期间，我们将继续遵循 Guido 关于迁移的建议：在我们的 2.x 代码库上运行 2to3，并修改 2.x 代码库以使其测试在两个版本中都能通过。

    这样做的结果是，直到我 35 岁生日之后，Python 3.x 才会成为 Twisted 的源语言——它将成为我的 python 2.x 代码的目标运行时（以及一组准则和限制）。我希望在接下来的十年左右使用 Python 2.x 编写程序。

所以，这就是计划。我希望它在一年左右的时间里看起来保守得可笑。3.x 过渡很容易，每个人都快速升级。其他事情也可能发生：2.x 和 3.x 分支可能会聚，有人最终可能会编写一个3to2，或者另一个运行时（想到 PyPy）可能允许同时运行 2.x 和 3.x 代码直接处理，使我们的转换过程更容易。

然而，就目前而言，我们假设，多年来，我们将拥有他们正在维护的大型代码库的人（或者编写新代码的人想要使用尚未迁移的其他库）仍然想要Twisted 中的新功能和错误修复。很快我希望我们也会有希望在 python 3 上使用 Twisted 的前沿用户。我想尽可能长时间地为所有这些人提供积极的体验。

于 2008-10-18T04:59:57.047 回答
8

Django 项目使用该库six来维护可同时在 Python 2和Python 3 上运行的代码库（博客文章）。

six通过提供一个兼容层来实现这一点，该层智能地将导入和函数重定向到它们各自的位置（以及统一其他不兼容的更改）。

明显优势：

  • Python 2 和 Python 3 不需要单独的分支
  • 没有转换工具，例如 2to3。
于 2012-10-26T22:00:41.660 回答
5

2.6 的主要思想是提供到 3.0 的迁移路径。因此，您可以from __future__ import X一次缓慢地迁移一项功能，直到确定所有功能并可以迁移到 3.0。3.0 的许多功能也将流入 2.6，因此您可以逐渐缩小语言差距，而不必一次性迁移所有内容。

在工作中，我们计划先从 2.5 升级到 2.6。然后我们开始慢慢启用 3.0 功能，一次一个模块。在某个时候，系统的整个子部分可能会为 3.x 做好准备。

唯一的问题是图书馆。如果一个库永远不会迁移，我们就会被旧库困住。但我非常有信心，我们会在适当的时候为这部分找到一个很好的替代方案。

于 2008-10-05T17:50:42.067 回答
3

作为图书馆作者发言：

我正在等待最终版本的发布。与大多数 Python 社区一样，我的信念是 2.x 将在数周或数月内继续成为主导版本。有足够的时间来发布一个漂亮的、经过优化的 3.x 版本。

我将维护单独的 2.x 和 3.x 分支。2.x 将向后兼容 2.4，所以我不能在 2.6 / 3.0 中使用很多花哨的语法或新功能。相比之下，3.x 分支将使用这些特性中的每一个，从而为用户带来更好的体验。测试套件将被修改，以便 2to3 可以使用它，我将为两个分支维护相同的测试。

于 2008-10-05T17:14:15.727 回答
3

两者都支持

我想尝试将 BeautifulSoup 库转换为我正在处理的项目的 3x，但我可以看到维护两个不同的代码分支是多么痛苦。

当前处理此问题的模型包括：

  1. 更改 2x 分支
  2. 运行 2to3
  3. 祈祷它第一次正确地进行转换
  4. 运行代码
  5. 运行单元测试以验证一切正常
  6. 将输出复制到 3x 分支

这个模型有效，但恕我直言，它很糟糕。对于每次更改/发布，您都必须完成这些步骤 ::sigh::。此外，它不鼓励开发人员使用只能在 py3k 中支持的新功能扩展 3x 分支，因为您基本上仍然将所有代码定位到 2x。

解决方案...使用预处理器

因为我找不到一个像样的带有#define 和#ifdef 指令的python 预处理器，所以我写了一个。

它被称为pypreprocessor，可以在 PYPI 中找到

本质上，您所做的是：

  1. 导入pypreprocessor
  2. 检测脚本在哪个版本的 python 中运行
  3. 在预处理器中为版本设置“定义”（例如“python2”或“python3”）
  4. 在代码特定于版本的地方撒上 '#ifdef python2' 和 '#ifdef python3' 指令
  5. 运行代码

就是这样。现在它可以在 2x 和 3x 下工作。如果您担心运行预处理器会增加性能损失，那么还有一种模式可以去除所有元数据并将后处理的源输出到文件中。

最重要的是……您只需进行一次 2to3 转换。

这是一个工作示例：

#!/usr/bin/env python
# py2and3.py

import sys
from pypreprocessor import pypreprocessor

#exclude
if sys.version[:3].split('.')[0] == '2':
    pypreprocessor.defines.append('python2')
if sys.version[:3].split('.')[0] == '3':
    pypreprocessor.defines.append('python3')

pypreprocessor.parse()
#endexclude
#ifdef python2
print('You are using Python 2x')
#ifdef python3
print('You are using python 3x')
#else
print('Python version not supported')
#endif

这些是终端中的结果：

python py2and3.py
 >>>你正在使用 Python 2x
 python3 py2and3.py
 >>>你正在使用 python 3x

如果要输出到文件并制作没有额外元数据的干净的特定于版本的源文件，请在 pypreprocessor.parse() 语句之前的某处添加这两行：

pypreprocessor.output = outputFileName.py
pypreprocessor.removeMeta = True

然后：

python py2and3.py

将创建一个名为 outputFileName.py 的文件，该文件是特定于 python 2x 的，没有额外的元数据。

python3 py2and3.py

将创建一个名为 outputFileName.py 的文件，该文件是 python 3x 特定的，没有额外的元数据。

有关文档和更多示例，请参阅GoogleCode 上的 pypreprocessor。

我真诚地希望这会有所帮助。我喜欢用 python 编写代码，我希望尽快看到支持进展到 3x 领域。我讨厌看到语言没有进步。尤其是，由于 3x 版本解决了许多特色 WTF，并使语法看起来对从其他语言迁移的用户更友好。

此时的文档是完整的，但并不广泛。我会尽快为 wiki 提供一些更广泛的信息。

更新：

虽然我专门设计了 pypreprocessor 来解决这个问题，但它不起作用，因为词法分析器在执行任何代码之前会对所有代码进行语法检查。

如果 python 有真正的 C 预处理器指令支持，它将允许开发人员在同一个文件中同时编写 python2x 和 python3k 代码，但由于 C 预处理器的坏名声（滥用宏替换来更改语言关键字）我不很快就会看到合法的 C 预处理器支持被添加到 python 中。

于 2010-06-04T21:32:10.560 回答
2

Zope Toolkit 对 Python 3 的支持进展缓慢。慢主要是因为许多这些库非常复杂。

对于大多数图书馆，我使用 2to3。一些库不需要它，因为它们很简单，或者大部分代码都在 C 扩展中。zc.buildout 是一个相关的包，将在没有 2to3 的情况下运行相同的代码以支持 Python 2 和 3。

我们将 ZTK 移植到 Python 3 是因为许多其他库和框架都依赖于它，例如 Twisted 和 Pyramid 框架。

于 2011-03-16T11:22:43.557 回答
0

我的一些更复杂的 2.x 代码将保持在 2.5 或 2.6。一旦我经常使用的一些第 3 方库更新为 3，我将转向 3.0 进行所有新开发。

于 2008-10-06T13:32:52.663 回答