你应该选择使用Python 2还是Python 3来进行开发？（五）

在一个共同代码基础上同时支持Python 2和Python 3

Python 2.6+ 和 Python 3.3+的共有子集相当大–Python3.3中恢复Unicode字符的u前缀支持意味着从语义上正确的Python 2.6+代码实现源码支持Python 3.3+而同时保有
大量的Python习惯用法。主要区别是有些东西需要从不同的地方导入，这样是为了处理他们在Python 2和Python 3中不同名的事实。

相应地，six compatibility package 是个关键的使用程序用于在一个单一的代码基础中支持Python 2和Python 3。

future compatibility package仍然处于beta状态并且不像six包支持那么多Python版本（它仅仅向后支持到Python 2.6， 而six包支持Python 2.4），但是允许Python 2兼容代码写成更接近Python 3习惯的风格（比如它包含一个实际的Python 3字节类型的Python 2兼容实现，而不是依赖Python 2.x 8位字符串类型–该类型暴露有些不同的API）。

标志标准库模块的另一个关键事情是看在PyPI上有没有一个更新的向后移植可优先用于2.x标准库版本。下列模块要么是PyPI向后移植，或者原始模块用作Python 2.7或者Python 3.x标准库附加项的来源（或者灵感）。

• unittest2（Michael Foord，标准库unittest维护者，至少需要2.6版本支持）
• mock（Michael Foord，标准库unittest.mock维护者）
• contextlib2（Nick Coghlan，标准库contextlib维护者）
• configparser（Łukasz Langa，标准库configparser维护者）
• futures（Alex Grönholm和Brian Quinlan，标准库concurrent.futures维护者）
• argparse（Steven Bethard，标准库argparse维护者，至少需要2.6版本支持）
• faulthandler（Victor Stinner，标准库faulthandler维护者）
• cdecimal（Stefan Krah，标准库decimal维护者）
• ipaddr（Peter Moody，标准库ipaddress维护者，Google IP地址操作模块灵感来自于标准库ipaddress模块的设计）
• stats（Steven D’Aprano，标准库statistics维护者）
• enum34（Ethan Furman，标准库enum维护者）
• funcsigs（Aaron Iles，函数签名对象的向后移植）
• shared namespace module for backports（Brandon Craig Rhodes）
• backport.inspect（Tripp Lilley，附加侦查模块变化的向后移植，基于funcsigs ）
• backports.datetime_timestamp（Jason R. Coombs，datetime.timestamp方法的向后移植，作为一个模块级函数接收日期时间对象）
• backports.pbkdf2（Christian Heimes，标准库hashlib维护者，hashlib.pbkdf2_hmac的向后移植）
• backports.ssl_match_hostname（Brandom Craig Rhodes 和 Toshio Kuratomi，ssl.match_hostname的向后移植）
• backports.lzma（Peter Cock，lzma封装器模块的向后移植）
• lzmaffi（Tomer Chachamu，替代lama向后移植，使用cffi获得更好的PyPy JIT兼容性）
• tracemalloc（Victor Stinner，标准库tracemalloc维护者）
• pathlib（Antoine Pitrou，标准库pathlib维护者）
• selectors34（Berker Peksag，标准库selectors模块的向后移植）

使用向后移植命名空间模块的优势在于它能清楚指示某个东西是一个标准库特性的跨版本向后移植，而且允许原始模块名称被使用如果合适且不跟原始库名称冲突。

在Python菜谱ActiveState中一些更小的Python 3附加项被用作食谱。

• functools.lru_cache（Raymond Hettinger）

下面的模块不是向后移植的，而是关键标准库API的跨版本兼容替代品：

• requests（更高层级HTTP和HTTPS APIs。由于各种各样的技术原因requests不太可能会被添加到标准库，但是一个对等的基于asyncio的API可能成为未来的标准库添加项）
• regex（一个正则表达式的替代引擎原则批准纳入最终的标准库，但是需要一个PEP来解决合作的详细问题）
• lxml.etree（ElementTree XML API 的替代实现）

除了上述模块也支持Python 2， Python 3.4添加到标准库的asyncio模块原来是为Python 3.3开发的一个PyPI模块。

• asyncio（Guido van Rossum，Python之父以及标准库asyncio维护者，要求Python 3.3添加语法“yield from”）

可以帮助选择Python 2或者Python 3的其它资源

• Community Web site to promote Python 3
• Nick Efford有一些关于使用Python 3教授编程的具体评论
  http://www.comp.leeds.ac.uk/nde/papers/teachpy3.html
• Mark Pilgrim写了一个Python 3版本的“一头扎进Python”
  http://getpython3.com/diveintopython3/
• Swaroop C H更新了使用Python 3的“Python一字节”，同时保持基于Python 2的最新版本可用http://www.swaroopch.com/notes/Python
• 一个IronPython用户需要知道的关于Python 3的东西
  http://www.itworld.com/development/104506/python-3-and-ironpython
• PyCon Ireland 2010收录了Paul Barry的主题为“一头栽进Python 3”的演讲，可在此查看：http://vimeo.com/groups/pyconireland/videos/14354395。Paul在PyCon Ireland 2011上继续发表了主题为“Python 3有什么缺陷?”的演讲，这里他更多谈到Python 3的被社区接收的不足，可在此查看：http://vimeo.com/groups/pyconireland/videos/31071871
• Mark Summerfield写了4页PDF总结了Python 2和Python 3的不同之处：Moving from Python 2 to Python 3
• Wesley Chun写了两篇Python 3的文章：Python 3：编程语言的革命（2009年3月）和Python“新”分区：Python 2对比Python 3（2010年1月）
• Wesley Chun的演讲和幻灯片：Python 3：下一个时代（PyCon，2010年2月）
• James Bennett 写了一篇有趣的文章讨论Python 3到底为什么能够存在？
• 如何让Python 2.x中的Unicode和字节类型语义跟Python 3.x中类似？（阻止暗示的编码和解码，同时保持有用的特性，比如str.split/bytes.split ）
• Nick Coghlan有一个常见问题页面包含了创建Python 3背后的很多基本原理的细节，预期的迁移计划，以及当前的过渡状态。

原文参考：
https://wiki.python.org/moin/Python2orPython3