【Python】学习笔记——-Python2 和 Python3的区别

有什么区别？

短版本：Python 2.x是遗留的，Python 3.x是语言的现在和未来

Python 3.0于2008年发布。最终的2.x版本2.7发布于2010年年中发布，其中包含了对此生命周期发布的扩展支持声明。2.x分支将没有看到新的主要版本。3.x正在积极开发，已经有五年以上的稳定版本，包括2012年版本3.3，2014年3.4，2015年3.5和2016年3.6。这意味着所有最近的标准库改进，例如，仅在Python 3.x中默认可用。

Guido van Rossum（Python语言的原创者）决定适当地清理Python 2.x，而不考虑向后兼容性，而不是2.x范围内的新版本。最大的改进是更好的Unicode支持（所有文本字符串默认为Unicode）以及saner字节/ Unicode分离。

此外，核心语言的几个方面（例如print和exec是语句，使用floor division的整数）已经被调整为更容易让新手学习，并且与其余的语言更一致，并且旧的cruft已经被移除（例如，所有类现在都是新式的，“range（）”返回一个内存高效的迭代，而不是如2.x中的列表）。

该有什么新的Python 3.0文档提供的主要语言的变化，并与现有的Python 2.x的代码不兼容的可能的来源一个很好的概述。尼克·科格伦（的CPython的核心开发者之一）还创建了一个比较详尽的常见问题有关的过渡。

然而，更广泛的Python生态系统已经积累了大量的质量软件多年来。在3.x中打破向后兼容性的缺点是，那些软件（特别是公司的内部软件）仍然不能在3.x上工作。

我应该使用哪个版本？

你应该使用哪个版本主要取决于你想做什么。

如果你能做到你想要的Python 3.x，太棒了！有一些小缺点，比如非常略差库支持¹和事实，即当前的一些Linux发行版和Mac电脑仍然使用2.X的默认（尽管Python 3中还附带了许多人），但作为一个Python语言3 .x绝对准备好了。只要Python 3.x安装在用户的计算机上（这应该很容易，因为许多人读这个可能只是为自己或他们控制的环境开发的东西），你在写的东西，你知道没有一个Python 2.x模块是必需的，它是一个很好的选择。此外，大多数Linux发行版本已经安装了Python 3.x，并且所有版本都可供最终用户使用。有些正在逐步淘汰Python 2作为预装的默认值。²

特别是，教官介绍Python来新程序员应该考虑教学的Python 3先介绍在Python 2的区别之后（如果需要的话），因为Python 3 消除了许多怪癖，可以不必要绊倒初级程序员努力学习Python 2。

但是，有一些关键问题可能需要您使用Python 2而不是Python 3。

• 首先，如果你部署到一个你不能控制的环境，那么可能会强加一个特定的版本，而不是允许你从可用的版本中自由选择。
• 其次，如果你想使用一个特定的第三方包或实用程序，它还没有一个与Python 3兼容的发布版本，并且移植这个包是一个不平凡的任务，你可以选择使用Python 2以保留对该包的访问。

Python 3已经广泛支持创建GUI应用程序，在标准库中使用Tkinter。Python 3中得到了支持PyQt的几乎是从天蟒3被释放; PySide加在2011年GTK +的GUI可以创建的Python 3支持PyGObject它支持Python 3和的前身是PyGTK的。

许多其他主要软件包已移植到Python 3，包括：

• numpy的和SciPy的（用于数字运算和科学计算）

• Django的，瓶，CherryPy的和金字塔（用于Web网站）

• PIL（图像处理模块）由其叉取代枕头，其支持Python 3。

• cx_Freeze（与它们的依赖包装应用）

• py2exe（包装为Windows用户您的应用程序）

• OpenCV的3，（一个开源计算机视觉和机器学习库）现在支持Python 3 3.0及更高版本。

• 请求，（用于人类的HTTP库）

• LXML，（一个强大的和Python的XML处理库相结合的libxml2 / libxslt上与ElementTree的 API）

• BeautifulSoup4，（解析HTML和XML格式的屏幕抓取库）

• 在IPython的 / Jupyter项目交互式计算完全支持Python 3。

• 还有很多，更多！

如果你想使用Python 3.x，但是你害怕因为依赖，这可能是值得做一些研究第一。这是一个正在进行的工作，此wiki页面可能已过时。此外，由于Python 2.6+和Python 3.3+都支持大的公共子集，许多现代的Python代码应该在Python 3上大部分未经修改运行，尤其是编写为与Web和GUI框架互操作的代码，这些代码强制应用程序正确区分二进制数据和文本（从一些协助6兼容性模块可能需要的处理名称变化。

尽管官方的Python文档和教程都为Python 3被完全更新，仍然有大量的文档在网络上，并在使用Python 2参考书（包括示例），虽然更多的正在更新所有的时间。这可能需要一些调整，使事情与Python 3工作。

有些人只是不想使用Python 3.x，这是他们的特权。然而，他们中的少数人。

如果你想使用另一种Python实现，如值得注意的是IronPython的，Jython的或Pyston（或Python平台或编译器的长列表中的一个实现），Python的支持3仍然是比较少见的。这可能会影响您，如果您有兴趣选择这样的实施，因为与其他系统集成或性能。

但是我不想避免2.x？这是一个有许多错误的老语言，它采取了一个主要的版本，让他们出去。

嗯，不完全。3.0和3.1中的一些破坏性较小的改进分别反馈到2.6和2.7。有关回迁功能的详细信息，请参阅在Python 2.6的新增功能和什么新的Python 2.7。

一个非完整的功能列表，仅在3.x版本中可用，不会反馈到2.x系列：

• 字符串默认是Unicode
• 干净的Unicode /字节分隔
• 异常链
• 函数注释
• 仅关键字参数的语法
• 扩展元组解包
• 非局部变量声明

此外，语言演进不限于核心语法或语义变化。同时把标准库，其中很多改进在3.X不会直接向后移植到Python 2.请做在Python 3新消息，例如。然而，许多标准库的改进也可以通过PyPI。

也就是说，良好的2.x代码可以很像3.x代码。这可能意味着许多事情，包括使用新式的类，不使用古老的弃用的奥秘咒语的印刷，在可用的时候使用惰性迭代器等。一个实际的例子：好的2.x代码通常使用xrange而不是范围; xrange是Python 3.x范围实现的起点（虽然范围在Python 3中更好，因为它可以处理大于sys.maxint的值）。应该注意，xrange（）不包括在Python 3中。

首先，建议你集中精力编写好的代码，以便2.X VS 3.x中变得不再是一个问题。这包括编写完整的单元测试套件，并使Unicode正确。（Python 3.x是明显比宽松比2.x关于Unicode对字节问题：这被认为是一件好事，虽然它使得移植一些软件包相当讨厌）。

我想使用Python 3，但有这个小的库我想使用的只是Python 2.x。我真的要恢复使用Python 2或放弃使用该库吗？

假设您找不到已经支持Python 3的替代软件包，您仍然需要考虑以下几个选项：

• 将库移植到3.x. （“移植”意味着您使库在3.x.上工作）
• 如果原来是真的很难，并且所有其他依赖关系确实存在于2.x中，请考虑在2.x中开始。正如在其他地方已经解释的，良好的2.x代码通常使得切换在每个依赖关系成功移植时无痛。
• 确定功能是否真的那么重要。也许你可以掉下来？

理想的情况是，您尝试将库移植到3.x. 通常你会发现有人已经在这方面工作。即使情况不是这样，现有的项目成员通常会喜欢这种帮助，特别是因为移植经常在原始软件中发现错误，提高原始和3.x端口的质量。移植并不总是容易，但它通常比从头开始编写自己的东西容易。

你应该如何做移植在此解释的Python 2移植指南。基本思想是采用2.x版本的库，并且在Python 2中使用-3命令行开关时，检查所有单元测试是否仍然通过而没有警告。如果测试失败或发出警告，请修改源，然后重试（这可能需要删除与旧版本的Python版本的兼容性）。一旦代码运行没有警告，当使用-3开关，然后尝试使用Python 3运行它。最好的情况是，当这个“只是工作” - 使用现代Python 2成语写的代码源兼容Python 3，因此它是可能的“端口”可以在这一点完成。

如果测试仍然Python的3下失败了，那么标准库的2to3的实用程序可以经常自动创建将Python 3下或者下运行的一个版本，阿明Ronacher的蟒蛇，现代化的工具，而不是目标的Python的公共子集2.6+，要么3.2+或3.3+（取决于使用的命令行选项）。（如果使用后者，重要的是检查仍然通过Python 2的测试）。

任一种方法都可以从单个2.x代码库并行地支持2.x和3.x。这比尝试并行维护单独的2.x和3.x分支要简单得多（只是问核心Python开发人员关于这一点的问题 - 他们已经坚持这样做了好几年了）。

如果在自动转换或现代化之后测试仍然失败，代码可能受到Python 2和3之间的语义变化的影响，转换器不能自动处理，并且未被-3开关检测到。这样的问题应该是罕见的，但可能仍然存在 - 如果遇到一个，值得提交一个bug，CPython要求一个新的-3警告。

如果涉及到C扩展模块，并且项目没有使用Cython，cffi或SWIG等自动处理Python 2和3之间的差异的包装生成器，那么移植情况可能会更复杂，但即使如此，它仍然可能是比发明自己的等效包更容易。该延长移植指南涵盖了一些关键的差异。

也有一些更深入的导游在这里在wiki上：PortingPythonToPy3k，PortingExtensionModulesToPy3k

我决定在3.x写一些东西，但现在有人想使用它只有2.x. 我该怎么办？

除了2to3的工具，它允许从2.x的源代码生成3.X代码，另外还有3to2工具，其目的是3.x的代码转换回2.X代码。在理论上，这应该比向另一个方向工作更好，因为3.x没有那么多的讨厌的转换器处理的情况下（摆脱，尽可能多的那些是可能的断裂的主要原因之一）向后兼容性！）。但是，大量使用仅3.x的功能（如功能注释或扩展元组解包）的代码不太可能成功转换。

这也许是公平的说，3to2是比2to3在这个阶段少了旅行的道路，所以你可能会遇到一些粗糙的边缘在这里和那里。然而，如果你想写3.x代码，这绝对是一个值得探索的想法。

在通用代码库中支持Python 2和Python 3

Python 2.6+和Python 3.3+的常见子集相当大 - 在Python 3.3中恢复unicode字面值的u前缀支持意味着语义正确的Python 2.6+代码可以与Python 3.3+源兼容，但仍然保留大部分习语Python 。主要的区别是，有些事情需要从不同的地方导入，以处理在Python 2和Python 3中有不同名称的事实。

因此，6兼容性包是在单个代码库支持的Python 2和Python 3的一个关键工具。

在未来的兼容性包仍处于测试阶段，不支持Python的，因为许多版本六（只可以追溯到像Python 2.6，尽管有六个支持Python 2.4），但允许Python 2兼容的代码进行编写方式更接近惯用的Python 3（例如，它包括实际的Python 2兼容的Python 3字节类型的实现，而不是依赖于暴露一个稍微不同的API的Python 2.x 8位字符串类型）。

确定标准库模块的另一个关键是如果在PyPI上有一个更新的反向端口，可以优先于2.x标准库版本。以下模块是PyPI backports，或者是作为Python 2.7或3.x中的标准库添加源（或灵感）的原始模块：

• unittest2（迈克尔Foord，STDLIB单元测试的维护者，大多需要2.6支持）

• 模拟（迈克尔Foord，STDLIB unittest.mock维护者）

• contextlib2（尼克·科格伦，STDLIB contextlib维护者）

• configparser（卢卡斯兰加，STDLIB configparser维护者）

• 期货（亚历克斯·格隆霍姆和布赖恩·昆兰，STDLIB concurrent.futures维护者）

• argparse（史蒂芬Bethard，STDLIB argparse维护者，大多需要2.6支持）

• faulthandler（维克多Stinner，STDLIB faulthandler维护者）

• cdecimal（斯特凡克拉，STDLIB小数维护者）

• IPADDR（彼得·穆迪，STDLIB ip地址的维护者，这激发了STDLIB ip地址模块的设计谷歌的IP地址，操作模块）

• 统计数据（史蒂芬D'Aprano，STDLIB统计维护者）

• enum34（伊桑·弗曼，STDLIB枚举维护者）

• funcsigs（亚伦尔斯，函数签名对象的反向移植）

• 对于反向移植共享命名空间模块（布兰登·克雷格罗德）

• backports.inspect（特里普李洁明的额外检查模块的变化反向移植，基于funcsigs）

• backports.datetime_timestamp（贾森R.库姆斯，datetime.timestamp方法作为模块级函数接受DateTime对象的反向移植）

• backports.pbkdf2（基督教海梅斯，STDLIB hashlib维护者，hashlib.pbkdf2_hmac的反向移植）

• backports.ssl_match_hostname（布兰顿克雷格·罗德和仓富俊夫，ssl.match_hostname的反向移植）

• backports.lzma（彼得公鸡的LZMA封装模块的反向移植）

• lzmaffi（Tomer的Chachamu，备用LZMA补丁包，使用CFFI更好PyPy JIT兼容性）

• tracemalloc（维克多Stinner，STDLIB tracemalloc维护者）

• pathlib（安托万Pitrou，STDLIB pathlib维护者）

• selectors34（的Berker Peksag的STDLIB选择模块的反向移植）

使用backports命名空间模块的优点是，它清楚地指示什么时候是标准库特性的交叉版本反向端口，并且还允许在适当时使用原始模块名称，而不与标准库名称冲突。

一些规模较小的Python 3中增加可作为食谱ActiveState的 Python的食谱。

* functools.lru_cache（雷蒙德的Hettinger）

以下模块不是反向端口，但是是关键标准库API的跨版本兼容的替代品：

• 请求（较高层次HTTP和HTTPS的API。请求本身不太可能被添加到STDLIB为什锦技术原因，但基于ASYNCIO等效客户端API是一个合理的未来加成）

• 正则表达式（在原则上批准，以便最终列入STDLIB替代正则表达式引擎，但需要PEP制定出结合的细节）

• lxml.etree（替代贯彻ElementTree的 XML API）

除了上面的模块也支持Python 2，asyncio模块添加到Python 3.4中的标准库最初是作为Python 3.3的PyPI模块开发的：

• ASYNCIO（吉多·范罗苏姆，BDFL和STDLIB ASYNCIO维护者，要求“收益率从”语法在Python 3.3添加）

其他可能有助于在Python 2和Python 3之间进行选择的资源

• 社区网站来推广Python 3

• 尼克Efford拥有与教学编程Python 3的一些具体意见：http://www.comp.leeds.ac.uk/nde/papers/teachpy3.html

• 马克朝圣者写“深入Python”的一个Python 3版本的重点：http://getpython3.com/diveintopython3/

• Swaroop CH已经更新了“Python的一个字节”使用Python 3，同时保持现有的最后的Python 2版本的基础：http://www.swaroopch.com/notes/Python

• “一个什么IronPython的用户应该知道的Python 3”：http://www.itworld.com/development/104506/python-3-and-ironpython

• PYCON爱尔兰2010包括保罗·巴里谈话题为“深入浅出到Python 3”，可以在这里找到：http://vimeo.com/groups/pyconireland/videos/14354395 -保罗从后续的谈话PYCON爱尔兰题为2011 “Python 3的勺子是什么？在那里，他更多地谈论（缺乏）的Python 3通过在社区内，可在这里：http://vimeo.com/groups/pyconireland/videos/31071871

• 马克·萨默菲尔德写了4页的PDF总结的Python 2和3之间的差异：移动在Python 2到Python 3

• 韦斯利春写了一些Python 3篇：Python的3：编程语言的演变（2009年3月）和Python的“新”事业部：Python的2对战的Python 3（2010年1月）

• 韦斯利春的Python的3：下一代通话及幻灯片（PYCON，2010年2月）

• 詹姆斯·贝内特写了一篇有趣的文章讨论了为什么Python的3.0存在于所有

• 如何获得的Unicode与字节语义2.x的类似于3.X的那些（防止隐式编码和解码，同时保持实用的功能，例如str.split / bytes.split

• 尼克·科格伦有一个常见问题的理由背后创建Python 3中，预期的迁移计划，以及过渡的当前状态盖很多细节

脚注

1. 当中仍然保持着包：https://python3wos.appspot.com （1）

2. Arch Linux的链接蟒蛇python3和Ubuntu和Fedora默认切换：https://wiki.ubuntu.com/Python/3 https://fedoraproject.org/wiki/Changes/Python_3_as_Default （2）