Python 很适合开发者使用。
无论你或你的客户用的是什么操作系统，都可以使用 Python。例如你可以在 Linux 上工
作，然后部署到其他系统上，除非你的代码与特定平台相关，或者用到了特定平台的库。但
这一特性已经不新鲜了（Ruby、Java 等很多其他语言都可以做到这一点）。本书还会讲到
Python 的其他特性，所有这些特性是使得 Python 成为一家公司主力开发语言的重要原因。
本书主要讲的是 Python 的 3.5 版本，如果没有明确说明的话，书中所有代码示例都是
用这个版本的 Python 编写的。由于这一版本尚未被广泛使用，本章将会向读者介绍一下
Python 3 的当前现状，同时介绍 Python 的现代开发方法。本章主要包括以下内容。
• 如何保持 Python 2 和 Python 3 之间的兼容性。
• 为了开发的顺利进行，在应用层面和操作系统层面如何解决开发环境隔离的问题。
• 如何增强 Python 提示符的功能。
• 如何使用 pip 安装 Python 包。
每本书的开头都要来点开胃小菜。如果你对 Python 已经很熟悉了（特别是最新的 3.x
版本），并且掌握了开发中做环境隔离的正确方法，你可以跳过本章的前两节，快速阅读其
他小节即可。其他小节会讲到一些工具和资源，它们并非必不可少，但可以大大提高 Python
开发效率。不过一定要读一下关于应用层环境隔离和 pip 的一节，因为这一节提到的工具
会在本书后面的内容中用到。
Python 升级及其原因
原因很简单。Python 升级是因为有这样的需求。语言之间的竞争随时都在上演。每隔
几个月都会突然冒出一门新语言，声称解决了之前所有语言中存在的问题。对于大多数类
似的项目，开发人员很快就会失去兴趣，它们的名气也只是一时炒作。
不管怎样，这也表示存在着更严重的问题。人们之所以设计新的编程语言，是因为他
们发现现有的语言无法以最佳方式来解决问题。认识不到这样的需求是目光短浅的。此外，
Python 的使用范围也越来越广泛，人们发现它有许多可以改进的地方，也应该做出这样的
改进。
Python 的很多改进往往是由特定应用领域的需求驱动的。其中最重要的领域是 Web 开
发，这一领域需要 Python 改进对并发的处理。
有些变化只是由于 Python 项目的历史原因导致的。这些年已经发现了 Python 的一些
不合理之处，有些是标准库模块结构混乱或冗余，有些是程序设计缺陷。最初，发布 Python
3 是要对这门语言进行较大的清理与更新，但结果显示，这个计划并没有收到预期的效果。
在很长一段时间内，很多开发人员对 Python 3 只是抱着好奇的态度而已，但希望这种情形
正在好转。
追踪 Python 最新变化——PEP 文档
Python 社区有一种应对变化的固定方法。虽然各种各样的 Python 语言修改意见主要在
邮件列表（python-ideas@python.org）中进行讨论，但只有发布了名为 PEP 的新文
档，新的变化才会生效。PEP 的全称是 Python 改进提案（Python Enhancement Proposal，
PEP）。它是提交 Python 变化的书面文档，也是社区对这一变化进行讨论的出发点。这些文
档的整个目的、格式和工作流程的标准格式也都包含在一份 Python 改进提案中，也就是 PEP 1
文档（http://www.python.org/dev/peps/pep-0001）。
PEP 文档对 Python 的作用十分重要，根据讨论的主题，PEP 主要有以下 3 种用途。
• 通知：汇总 Python 核心开发者需要的信息，并通知 Python 发布日程。
• 标准化：提供代码风格、文档或其他指导意见。
• 设计：对提交的功能进行说明。
如果你对 Python 语言的未来发展方向感兴趣，但又没时间跟踪 Python 邮件列表中的
讨论，那么 PEP 0 会是很好的信息来源。它会告诉你，哪些文档已被接受但尚未实施，哪
些文档仍在审议中。
PEP 还有其他的用途。人们通常会问这样的问题：
• A 功能为什么要以这样的方式运行？
• Python 为什么没有 B 功能？
大多数情况下，关于该功能的某个 PEP 文档已经给出了上述问题的详细回答。很多提
交的关于 Python 语言功能的 PEP 文档并没有通过。这些文档可作为历史资料来参考。
当前 Python 3 的普及程度
Python 3 有许多强大的新功能，那么它在社区中广泛普及了吗？遗憾的是，并没有。
有一个著名的网站叫“Python 3 荣耀之墙（Python 3 Wall of Superpowers）”，里面记录了大
多数常用软件包与 Python 3 的兼容性，不久前这个网站刚刚改名为“Python 3 耻辱之墙
（Python 3 Wall of Shame）”。目前这种状况正在逐步改善，上述网站的软件包列表中绿色的
比例也在每月缓慢增加①。尽管如此，但这并不代表很快所有应用开发团队都只使用 Python
3。当所有常用软件包都支持 Python 3 时，“我们所用的软件包还没有迁移到 Python 3”这
一常用借口将不再适用。
造成目前这种状况的主要原因是，将现有应用从 Python 2 迁移到 Python 3 上总是一项
不小的挑战。像 2to3 之类的工具可以进行代码自动转换，但无法保证转换后的代码 100%
正确。而且，如果不做人工修改的话，转换后的代码性能可能不如转换前。将现有的复杂
代码库迁移到 Python 3 上可能需要付出巨大的精力和成本，某些公司可能无法负担这些成
本。但这些成本可以分割成小份来逐步完成。一些优秀的软件架构设计方法可以帮助其逐
步实现这一目标，如面向服务的架构或者微服务。新的项目组件（服务或微服务）可以用
新方法编写，现有的项目组件可以逐步迁移。
长远来看，将项目迁移到 Python 3 只有好处。根据 PEP-404 这份文档，Python 2.x 分
支将不会发布 2.8 版本。而且未来所有重要的项目（如 Django、Flask 和 NumPy）可能都
将放弃 2.x 的兼容性，仅支持 Python 3。