您打算如何处理到Python3的迁移？


How are you planning on handling the migration to Python 3?

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

  • 您将同时维护python 2和python 3版本，还是在完成后只维护python 3版本？

    • 你已经开始了吗？还是计划很快开始？或者你打算等到最后一个版本发布后再全面发布？
    • 相关讨论

    这是扭曲的总计划。我本来打算把这个写在博客上，但后来我想：当我能为它得分时，为什么还要写博客呢？好的。

  • 等到有人关心。好的。

    现在，没有人有python 3。在至少有一个实际用户出现并说"我需要Python3.0支持"之前，我们不会花费大量的精力，除了3.0看起来很有光泽之外，我们还有充分的理由支持它。好的。

  • 等到我们的依赖关系迁移。好的。

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

    • Zope界面
    • 隐睾
    • 脓毒症
    • PyWi32
    • Pygtk(尽管这种依赖性现在很轻，但当迁移开始时，我希望Twisted会有更多的GUI工具)
    • PYASN1
    • 吡喃
    • GMPY

    其中一些项目有自己的依赖项数组，因此我们也必须等待它们。好的。

  • 等到有人愿意帮忙。好的。

    有5个人很有魅力地从事扭曲的工作——我说"很有魅力"，因为这算上我，而且我已经好几个月没有承诺过了。我们现在有1000多张开放的门票，在花时间将其移植到一个全新版本的语言之前，实际修复其中的一些漏洞、添加功能，并且通常可以自行使Twisted成为更好的产品，这将是一件好事。好的。

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

  • 听从吉多的建议。好的。

    这意味着我们将不会不兼容地改变我们的API，我们将遵循guido去年发布的过渡开发指南。首先进行单元测试，然后在扭曲的代码库上运行2to3转换工具。好的。

  • 报告2to3工具的错误并为其提供补丁。好的。

    当我们到了实际使用它的时候，我预计在将来运行2to3会有很多问题。现在在Twisted上运行它需要非常长的时间，并且(上次我检查，这是很久以前的)无法解析Twisted存储库中的一些文件，因此结果输出将不会导入。我认为在这个工具真正为我们工作之前，必须有大量的小项目的成功案例和对它的大量锤炼。好的。

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

  • 在几年内保持2.x兼容性。好的。

    现在，Twisted支持python 2.3到2.5。目前，我们正在研究2.6支持(显然我们必须在3.0之前完成！)我们的计划是在长期支持的Ubuntu 8.04版本(包括python 2.5)的基础上修改我们支持的python版本，直到2013年才会得到支持。根据Guido的建议，为了支持3.0，我们需要放弃对2.5的支持，但我希望我们能找到一种解决方法(我们对版本兼容性黑客非常有创意)。好的。

    因此，我们计划至少在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代码，从而使转换过程更容易。好的。

    然而，目前，我们假设，多年来，我们将有人拥有他们正在维护的大型代码库(或有人编写新代码，希望使用其他尚未迁移的库)，他们仍然希望新功能和错误修复扭曲。很快，我预计我们还会有一些出血边缘的用户想要在python 3上使用twisted。我想为所有这些人提供尽可能长的积极经验。好的。好啊。

    相关讨论

    django项目使用库six来维护一个同时在python2和python3(blog post)上工作的代码库。

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

    明显优势：

    • 对于python2和python3不需要单独的分支
    • 没有转换工具，如2to3。
    相关讨论

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

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

    唯一的问题是图书馆。如果一个库从未迁移过，那么我们就只能使用旧库。但我很有信心，我们会在适当的时候为这部分找到一个好的选择。

    既支持

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

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

  • 更改2X分支
  • 运行2to3
  • 祈祷它能在第一次正确地进行转换。
  • 运行代码
  • 运行单元测试以验证是否一切正常
  • 将输出复制到3x分支

    • 这个模型行得通，但我觉得它糟透了。对于每一个变更/发布，您都必须经历以下步骤：：叹息：：。另外，它不鼓励开发人员使用PY3K中只能支持的新功能来扩展3X分支，因为您基本上仍然将所有代码都指向2X。

    解决方案…使用预处理器

    因为我找不到一个合适的C风格的预处理器，它带有针对python的define和ifdef指令，所以我写了一个。

    它叫做pypreprocessor，可以在pypi中找到

    基本上，你要做的是：

  • 导入PyPreprocessor
  • 检测运行脚本的python版本
  • 在预处理器中为版本设置"define"(例如"python2"或"python3")。
  • 在代码特定于版本的地方，sproup'ifdef python2'和'ifdef python3'指令
  • 运行代码

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

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

    这是一个很好的例子：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    #!/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

    这些是终端中的结果：

    1
    2
    3
    4
     python py2and3.py
     >>>You are using Python 2x
     python3 py2and3.py
     >>>You are using python 3x

    如果要输出到一个文件并在没有额外元数据的情况下生成干净的特定于版本的源文件，请在pypreprocessor.parse()语句之前的某个位置添加这两行：

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

    然后：

    1
    python py2and3.py

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

    1
    python3 py2and3.py

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

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

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

    此时的文档是完整的，但并不广泛。我很快会尝试用更广泛的信息来建立wiki。

    更新：

    尽管我专门为解决这个问题而设计了pypreprocessor，但它不起作用，因为lexer在执行任何代码之前都会对所有代码进行语法检查。

    如果python有真正的c预处理器指令支持，它将允许开发人员在同一个文件中同时编写python2x和python3k代码，但是由于c预处理器的坏名声(滥用宏替换来更改语言关键字)，我认为任何时候都不会向python添加合法的c预处理器支持。

    以图书馆作者的身份发言：

    我正在等待最终版本的发布。我相信，和大多数Python社区一样，2.x将在数周或数月内继续成为主流版本。这是释放一个漂亮的，抛光的3.x释放大量的时间。

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

    相关讨论

    Zope工具包在支持Python3方面进展缓慢。慢主要是因为这些库中的许多非常复杂。

    对于大多数库，我使用2to3。有些库之所以不使用它，是因为它们很简单，或者在C扩展中拥有大部分代码。作为一个相关的包，zc.buildout将运行相同的代码，而不需要2to3来支持python 2和3。

    我们将ztk移植到python3，因为许多其他的库和框架都依赖于它，比如twisted和pyramid框架。

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