为什么人们会犹豫使用Python 3？

Python 3于2008年12月发布。从那时起已经过去了很多时间，但是直到今天，许多开发人员仍在犹豫使用Python3。甚至流行的框架（如Django）仍不兼容Python 3，但仍依赖于Python 2。

当然，Python 3与Python 2有一些不兼容，有些人需要依靠向后兼容。但是，对于大多数项目来说，Python 3的存在时间是否已经足够长，以至于大多数项目都无法切换或开始使用Python 3？

有两个竞争版本有很多缺点。需要保持两个分支，学习者的困惑等等。那么，为什么在整个Python社区中对于切换到Python 3如此犹豫？

请注意，我不再更新此答案。我在http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html的个人网站上有更长的Python 3问答环节。

先前的答案：

（状态更新，2012年9月）

我们（即Python核心开发人员）预测Python 3.0发行时，将3.x变成大约2.x系列新项目的“默认”选择大约需要5年。该预测就是为什么2.7版本的计划维护期如此之长的原因。

最初的Python 3.0版本还发现了一些关键问题，它们的IO性能不佳，导致实际上无法用于大多数实际目的，因此从2009年6月下旬发布Python 3.1开始时间表是比较有意义的。 IO性能问题也是没有3.0.z维护版本的原因：没有充分的理由要有人坚持使用3.0而不是升级到3.1。

在撰写本文时（2012年9月），这意味着我们目前距离过渡过程还有3年多的时间，而且这种预测似乎仍在轨道上。

尽管人们在输入 Python 3代码时经常受到语法变化（例如print变成函数）的咬伤，但这实际上并不是库移植的麻烦，因为自动2to3转换工具可以很轻松地处理它。

实际上，最大的问题实际上是一个语义上的问题：Python 3不允许您像Python 2那样快速随意地使用文本编码。这既是它相对于Python 2的最大好处，也是移植的最大障碍：您必须解决 Unicode处理问题才能使端口正常工作（而在2.x中，许多代码静默地生成了错误的数据，非ASCII输入，给人以工作的印象，特别是在非ASCII数据不常见的环境中）。

甚至Python 3.0和3.1中的标准库仍然存在Unicode处理问题，因此很难移植很多库（尤其是与Web服务相关的库）。

3.2解决了许多此类问题，为Django等库和框架提供了更好的目标。3.2还带来了wsgiref3.x 的第一个工作版本（用于Web服务器和用Python编写的Web应用程序之间的通信的主要标准），这是在Web空间中采用的必要先决条件。

现在已经移植了NumPy和SciPy之类的关键依赖项，例如，并已安装了安装和依赖项管理工具zc.buildout，pip并且virtualenv可用于3.x。Pyramid1.3版本支持Python 3.2，即将发布的Django 1.5版本包括实验性Python 3支持，以及12.0版本的Twisted网络框架放弃了对Python 2.5的支持，从而为创建兼容Python 3的版本铺平了道路。

除了在Python 3兼容性库和框架方面取得进展之外，流行的JIT编译的PyPy解释器实现还积极地支持Python 3。

用于管理迁移过程的工具也已显着改进。除了2to3作为CPython的一部分提供的工具（现在认为该工具最适合不需要维护2.x系列的应用程序的一次性转换）之外，还有python-modernize，它使用2to3基础结构来定位Python 2和Python 3的（大型）公共子集。此工具将创建一个代码库，借助six兼容性库，该代码库将在Python 2.6+和Python 3.2+上运行。迁移现有的Unicode感知应用程序时，Python 3.3发行版还消除了“噪声”的一个主要原因：Python 3.3再次支持字符串文字的“ u”前缀（实际上并没有这样做）Python 3中的任何内容-刚进行了恢复，以避免对已经正确区分了Python 2中的文本和二进制文字的用户无意间使迁移到Python 3 变得更加困难。

因此，我们实际上对事情的进展感到非常满意-在我们的原始时间框架上还有将近2年的时间，而且整个Python生态系统中的变化都很好地荡漾着。

由于许多项目无法正确地整理其Python包索引元数据，并且一些维护者活动较少的项目也被派来添加对Python 3的支持，因此纯自动化的PyPI扫描程序仍然对Python 3库的状态给出了过分的否定看法支持。

在PyPI上获取有关Python 3支持级别的信息的首选方法是http://py3ksupport.appspot.com/

此列表由Brett Cannon（长期的Python核心开发人员）亲自策划，以解决不正确的项目元数据，源代码管理工具中尚未正式发布的Python 3支持以及具有最新分支的项目或支持Python 3的替代方案。在许多情况下，Python 3上尚不可用的库缺少关键的依存关系和/或其他项目中缺少Python 3的支持会减少用户需求（例如，一旦Django核心框架在Python 3，South和django-celery等相关工具更可能增加对Python 3的支持，并且Pyramid 和 Django 中都提供Python 3支持，这使得在其他工具（如gevent）中实现Python 3支持的可能性更高。

该网站位于http://getpython3.com/，其中包含指向 Python 3的书籍和其他资源的出色链接，确定了一些已经支持Python 3的关键库和框架，还提供了有关开发人员如何从Java 3寻求财务帮助的信息。 PSF将关键项目移植到Python 3。

另一个不错的资源是社区Wiki页面，其中介绍了在为新项目选择Python版本时要考虑的因素：http : //wiki.python.org/moin/Python2orPython3

我相信很多犹豫来自两件事：

• 如果还没有破裂，请不要修复
• [XYZ库]我们要求没有3.0端口

本文档概述了核心语言的行为方式，其中有很多差异。例如，将“打印”从一条语句更改为一个函数之类的简单操作将破坏大量的Python 2.x代码-这只是最简单的操作。他们在3.0中完全摆脱了较旧的类。实际上，它们是完全不同的语言-因此移植旧代码并不像某些人想象的那么简单。

现有企业没有强迫理由花费时间，金钱和精力迁移到某样东西，而现有功能集却没有变化。我的意思是说基于Python 2系列的代码已经在企业中运行并运行了很长时间，其稳定，经过测试并具有所有当前产品功能集。为什么有人会花时间，金钱和精力只是为了迁移到Python 3而已。

除了迁移后，还要确保没有回归失败，而且所有头痛都是不可避免的。

对于新项目，该策略是简单明了的，它始于以下几点：

1. 是否有任何发行版（如Ubuntu）在默认安装中附带Python 3？
2. 什么是Python 3的库生态系统？
3. 所有框架等都与Python 3等兼容吗？

它是您通常的“选择一种新语言”的过程。这就是出现鸡鸡蛋问题的地方，没有多少人在使用它，因为没有多少人在使用它。最终，没有人会感觉完全转向它。

打破向后兼容性从来都不是一件好事，在最后，您总是会吸引很多用户。

在Python 2.0发行之时，Python迅速普及。有许多新用户自然使用最新版本，因为他们不依赖旧版本。由于许多人默认采用2.0，因此库开发人员等面临很大压力。

到发布Python 3.0时，已经有大量的用户依赖Python 2.0，并且指数增长（相对于现有用户而言保持恒定的因素）显然无法无限持续。

就个人而言，Python 2天内的新功能似乎比Python 3所提供的功能更具吸引力。

我曾经以为Python 3最终会接管一切，但是现在我不确定。但是，不仅仅是这个问题存在于Python中。毕竟，有多少人诚实地使用Perl 6？这大约比Python 3 IIRC长一点。

对我来说，最大的障碍是整数除法，我认为无法通过自动翻译解决。我有依靠x / 2的科学代码，将x舍入（当x为整数时）。

Python 3不会这么做，但是会给出.5答案（对于奇数x）。
我不能只用//替换代码中的所有/，因为有时我会进行浮点除法，因此希望进行浮点运算。

因此，要移植到python 3，我将不得不遍历数万行代码，检查每个/，并查看是否可以确定它应该是/或//。

如果您需要的所有库都已移植到Py3k，则 Python 3可以很好地启动一个新项目。

如果这不是一个选择，那么使用Python 2.7是两全其美的方法：您拥有为Python 2.x创建的每个库，并且可以逐渐将代码更改为与Py3k兼容，因此在您决定使用时易于迁移它。您在2.7中已经拥有的来自Py3k的语法好东西列表很长，只是不要忘记从中导入__future__。我的最爱默认情况下是Unicode，除法总是产生浮点数。

从Web服务的角度来看：主要服务器框架和Web框架都不支持Python3。

更新：显然，这是2011年初的情况，截至目前（2013年底），大多数主要框架都在使用Python3。但是，有些仍然不兼容。重要的例子是Twisted，它仍在进行中。

除非您从事繁重的i18n工作，否则我没有使用P3K的令人信服的理由。在我的尝试中，我发现普遍使用的Unicode成为我（ASCII）工作的障碍，也是强制生成器阻塞我的代码的障碍。

几年后，3将呈现出更加引人注目的环境，但今天不是。

发行版不使Python3可用。有一些附带发行版已经从Python2过渡了。但是主流的Linux变体（例如Debian，Ubuntu等）却没有。这就是我作为应用程序作者不执行任何操作的主要原因。

尽管我准备了过渡，甚至尝试避免不兼容的语法构造，但我无法对其进行适当的测试。真正归结为鸡肉和鸡蛋问题。