聊聊Python

Python很棒！

从20世纪80年代末出现的最先版本到当前版本，Python的发展一直遵循着相同的理念：提供一个同时具有可读性和生产力的多范式编程语言。

人们曾经将Python看做另外一种脚本语言，认为它不适合构建大型系统。但多年以来，在一些先驱公司的努力下，Python显然能够用于构建几乎任何类型的系统。

实际上，许多其余语言的开发者也醉心于Python，并将它做为首选语言。

1.1　Python的现状与将来

Python的历史最先可追溯到20世纪80年代末，可是1.0版的发行时间是在1994年，因此Python并非一门很是年轻的语言。这里本该介绍Python主要版本发布的整个时间线，但其实真正重要的日期只有一个：2008年12月3日，也就是Python 3.0的发布日期。

在写做本书时，Python 3的首次发布已通过去了7年。PEP 404也已经建立了4年，PEP 404是“取消发布"（un-release）Python 2.8并正式关闭Python 2.x分支的官方文档。虽然过去了这么长的时间，Python 社区中依然存在明显的分歧。语言自己在迅速发展，但大量用户却并不想更新版本。

1.2　Python升级及其缘由

缘由很简单。Python升级是由于有这样的需求。语言之间的竞争随时都在上演。每隔几个月都会忽然冒出一门新语言，声称解决了以前全部语言中存在的问题。对于大多数相似的项目，开发人员很快就会失去兴趣，它们的名气也只是一时炒做。

无论怎样，这也表示存在着更严重的问题。人们之因此设计新的编程语言，是由于他们发现现有的语言没法以最佳方式来解决问题。认识不到这样的需求是目光短浅的。此外，Python的使用范围也愈来愈普遍，人们发现它有许多能够改进的地方，也应该作出这样的改进。

Python的不少改进每每是由特定应用领域的需求驱动的。其中最重要的领域是Web开发，这一领域须要Python改进对并发的处理。

有些变化只是因为Python项目的历史缘由致使的。这些年已经发现了Python的一些不合理之处，有些是标准库模块结构混乱或冗余，有些是程序设计缺陷。最初，发布Python 3是要对这门语言进行较大的清理与更新，但结果显示，这个计划并无收到预期的效果。在很长一段时间内，不少开发人员对Python 3只是抱着好奇的态度而已，但但愿这种情形正在好转。

1.3　追踪Python最新变化——PEP文档

Python社区有一种应对变化的固定方法。虽然各类各样的Python语言修改意见主要在邮件列表（python-ideas@python.org）中进行讨论，但只有发布了名为PEP的新文档，新的变化才会生效。PEP的全称是Python改进提案（Python Enhancement Proposal，PEP）。它是提交Python变化的书面文档，也是社区对这一变化进行讨论的出发点。这些文档的整个目的、格式和工做流程的标准格式也都包含在一份Python改进提案中，也就是PEP 1文档（www.python.org/dev/peps/pe…

PEP文档对Python的做用十分重要，根据讨论的主题，PEP主要有如下3种用途。

• 通知：汇总Python核心开发者须要的信息，并通知Python发布日程。

• 标准化：提供代码风格、文档或其余指导意见。

• 设计：对提交的功能进行说明。

全部提交过的PEP都被汇总在一个文档中，就是PEP 0（www.python.org/dev/peps/）。…

若是你对Python语言的将来发展方向感兴趣，但又没时间跟踪Python邮件列表中的讨论，那么PEP 0会是很好的信息来源。它会告诉你，哪些文档已被接受但还没有实施，哪些文档仍在审议中。

PEP还有其余的用途。人们一般会问这样的问题：

• A功能为何要以这样的方式运行？

• Python为何没有B功能？

大多数状况下，关于该功能的某个PEP文档已经给出了上述问题的详细回答。不少提交的关于Python语言功能的PEP文档并无经过。这些文档可做为历史资料来参考。

1.4　当前Python 3的普及程度

Python 3有许多强大的新功能，那么它在社区中普遍普及了吗？遗憾的是，并无。有一个著名的网站叫“Python 3荣耀之墙（Python 3 Wall of Superpowers）”，里面记录了大多数经常使用软件包与Python 3的兼容性，不久前这个网站刚刚更名为“Python 3耻辱之墙（Python 3 Wall of Shame）”。目前这种情况正在逐步改善，上述网站的软件包列表中绿色的比例也在每个月缓慢增长^[1]。尽管如此，但这并不表明很快全部应用开发团队都只使用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。

我我的对这个问题的观点可能会引起争议。我认为在建立新的软件包时，最好鼓励社区彻底放弃支持Python 2。固然，这一作法极大地限制了这些软件的适用范围，但对于那些坚持使用Python 2.x的人来讲，这多是改变他们想法的惟一方法。

1.5　Python 3和Python 2的主要差别

前面已经说过，Python 3打破了对Python 2的向后兼容。但它并非彻底从新设计的。并且，也并非说2.x版本的Python模块在Python 3下都没法运行。代码能够彻底跨版本兼容，无需其余工具或技术在两大版本上均可以运行，但通常只有简单应用才能作到这一点。

1.5.1　为何要关注这些差别

本章前面说过我我的对Python 2兼容性的见解，可是目前不可能彻底忽视这一点。还有一些Python包（例如第6章将讲到的fabric）十分实用，但可能短时间内不会迁移到Python 3。

另外，有时咱们还会受到所在公司的制约。现有的遗留代码可能很是复杂，迁移代码的费用难以承受。因此即便咱们如今决定只用Python 3，短时间内也不可能彻底放弃Python 2。

现在想要自称专业开发者，没有对社区的回馈是说不过去的，因此帮助开源软件开发者向现有软件包中添加对Python 3的兼容，能够很好地偿还在使用这些软件包时产生的“道德债（moral debt）”。固然，不了解Python 2和Python 3的差别是没法作到这一点的。顺便提一下，对于Python 3新手来讲，这也是一项很好的练习。

1.5.2　主要的语法差别和常见陷阱

要比较不一样版本之间的差别，最好的参考资料就是Python文档。不过为了方便读者，本节总结了其中最重要的内容。但不熟悉Python 3的读者仍是要去阅读官方文档。

Python 3引入的重要差别通常可分为如下几个方面。

• 语法变化，删除/修改了一些语法元素，并添加了一些新的语法元素。

• 标准库中的变化。

• 数据类型与集合的变化。

1．语法变化

有些语法变化会致使当前代码没法运行，这些变化是最容易发现的，它们会致使代码根本没法运行。包含新语法元素的Python 3代码在Python 2中没法运行，反之亦然。因为删除了某些元素，致使Python 2代码显然没法与Python 3兼容。运行有这些问题的代码时，解释器很快就会抛出SyntaxError异常。下面是一个没法运行的脚本示例，只包含两个语句，都会引起语法错误而没法运行：

 print("hello world") print "goodbye python2"

上述代码在Python 3中的实际运行结果以下：

$ python3 script.py File "script.py", line 2 print "goodbye python2" ^SyntaxError: Missing parentheses in call to 'print'

列出全部的语法差别会比较长，并且Python 3.x的新版本也会不时添加新的语法元素，在较早版本的Python中就会引起错误（即便在相同的3.x版本上也会报错）。其中最重要的语法差别将会在第2章和第3章中讲到，因此这里无需所有列出。

与Python 2.7相比，删除或改动的内容要相对少一些，下面给出最重要的变化内容。

• print再也不是一条语句而是一个函数，因此必须加上括号。

• 捕获异常的语法由except exc, var改成except exc as var。

• 弃用比较运算符<>，改用!=。

• from module import （docs.python.org/3.0/referen…

• 如今from .[module] import name是相对导入的惟一正确的语法。全部不以点字符开头的导入都被看成绝对导入。

• sorted函数与列表的sort方法再也不接受cmp参数，应该用key参数来代替。

• 整数除法表达式（如1/2）返回的是浮点数。取整运算能够用//运算符，如1//2。这样作的好处是浮点数也能够用这个运算符，因此5.0//2.0 == 2.0。

2．标准库中的变化

语法变化很容易发现，标准库中的重大变化也是很是容易发现的。Python的每一个后续版本都会向标准库模块中添加、弃用、改进或彻底删除某些内容。在旧版Python（1.x和2.x）中也会按期有这样的变化，因此出如今Python 3中并不让人吃惊。大多数状况下，对于删除或重组的模块（例如urlparse移到了urllib.parse），在运行解释器时会对导入语句抛出异常。这样的问题很容易发现。不管如何，为了确保可以发现全部相似的问题，完整的代码测试覆盖率是必不可少的。在某些状况下（例如使用延迟加载模块时），这个一般在全局导入时出现的问题并不会出现，直到在代码中将某些模块做为函数调用时才会出现。所以，在测试期间确保每行代码都要实际运行是很重要的。

　

延迟加载模块

延迟加载模块是指在全局导入时并不加载的模块。在Python中，import语句能够包含在函数内部，这样导入是在函数调用时才会发生，而不是在全局导入时发生。在某些状况下，模块的这种加载方式可能比较合理，但大多数状况下，这只是对设计不佳的模块结构的变通方法（例如避免循环导入），一般应避免这种加载方式。固然，对于标准库模块来讲，没有理由使用延迟加载。

3．数据类型与集合的变化

开发人员在努力保持兼容性或只是将现有代码迁移到Python 3上时，须要特别注意Python中数据类型与集合的表示方式的变化。虽然不兼容的语法变化或标准库变化很容易发现，也很容易修复，但集合与数据类型的变化要么难以察觉，要么须要大量的重复工做。这样的变化列表会很长，再次重申，官方文档是最好的参考资料。

不过，这一节必须讲一下Python 3中字符串处理方式的变化，由于这是Python 3中最具争议也是讨论最多的变化，尽管这是一件好事，使不少问题变得更加明确。

如今全部字符串都是Unicode，字节（bytes）须要加一个b或B的前缀。Python 3.0和3.1不支持使用u前缀（例如u"foo"），使用的话会引起语法错误。不支持这个前缀是引起全部争议的主要缘由。这致使难以编写可以兼容Python不一样分支的代码，2.x版须要用这个前缀来建立Unicode。Python 3.3又恢复了这个前缀，虽然没有任何语法上的意义，只是为了简化兼容过程。

1.5.3　用于保持跨版本兼容性的经常使用工具和技术

在Python不一样版本之间保持兼容性是一项挑战。根据项目的大小不一样，这项挑战可能会增长许多额外的工做量，但绝对可行，也很值得去作。对于在许多环境中都会用到的Python包来讲，必需要保持跨版本兼容性。若是开源包没有定义明确并通过测试的兼容范围（compatibility bound），是不太可能流行起来的。并且，对于只在公司网络封闭使用的第三方代码来讲，也能够大大受益于在不一样环境中的测试。

这里应该注意，虽然这一部份内容主要关注Python不一样版本之间的兼容，但这些方法也适用于保持与外部依赖项之间的兼容，外部依赖项包括不一样的包版本、二进制库、系统或外部服务等。

整个过程主要分为3个部分，按重要性排序以下。

• 定义并记录目标兼容范围的及其管理方法。

• 在每一个环境中进行测试，并对每一个兼容的依赖版本进行测试。

• 实现实际的兼容代码。

告知兼容范围是整个过程当中最重要的一部分，由于这可让代码使用者（开发人员）对代码的工做原理和将来的变化方式有必定的预期和假设。咱们的代码可能用于多个不一样项目的依赖，这些项目也在努力管理兼容性，因此把代码兼容性说清楚仍是很重要的。

本书老是尽可能给出几个选择，而不会强烈推荐某个特定选项，而这里是少数几个例外之一。目前来看，管理兼容性将来变化的最佳方法，就是正确使用语义化版本（Semantic Versioning semver）的版本号。它是一个广为接受的标准，用仅包含3个数字的版本标识符来标记代码的变化范围。它还给出了如何处理弃用的方法建议。下面是摘录semver官网的摘要。

版本格式：主版本号.次版本号.修订号，版本号递增规则以下。

• 主版本号（MAJOR）：当你作了不兼容的API修改。

• 次版本号（MINOR）：当你作了向后兼容的功能性新增。

• 修订号（PATCH）：当你作了向后兼容的问题修正。

先行版本号及版本编译信息能够加到“主版本号.次版本号.修订号”的后面，做为延伸。

测试时就会发现一个悲伤的事实，为了保证代码与每一个依赖版本和每一个环境（这里环境指的是Python版本）都保持兼容，必须在全部可能的组合中对代码进行测试。固然，若是项目的依赖不少，作到这一点基本是不可能的，由于随着依赖版本数目的增长，组合的数目也会迅速增长。所以，一般须要作一些权衡，使得运行全部兼容性测试无需花费数年的时间。第10章中介绍通常的测试，里面也介绍了所谓的矩阵测试中工具的选择。

　

项目遵循semver的好处在于，一般只有主版本才须要测试，由于次版本和修订版本中保证没有向后不兼容的变化。只有项目不违背这样的约定，这种说法才能成立。不幸的是，每一个人都会犯错，许多项目中都出现了后向不兼容的变化，甚至在修订版本中也出现了这种变化。尽管如此，因为semver声称对次版本和修订版本的变化保持严格的向后兼容，那么打破这个规则就能够视为bug，能够在修订版本中进行修复。

若是明肯定义了兼容范围并严格测试，那么实现兼容层就是最后一步，也是最不重要的一步。可是，每一位对这个话题感兴趣的程序员都应该知道下列工具和技术。

最基本的就是Python的future模块。它将Python新版本中的一些功能反向迁移到旧版本中，采用的是导入语句的形式：

 from future import <feature>

future语句提供的功能是和语法相关的元素，其余方法很难处理这些元素。这个语句只能影响它所在的模块。下面是Python 2.7交互式会话的实例，从Python 3.0中引入Unicode：

Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit(Intel)] on win32Type "help", "copyright", "credits" or "license" for moreinformation.>>> type("foo") # 旧的字面值<type 'str'>>>> from future import unicode_literals>>> type("foo") # 如今变成了unicode<type 'unicode'>

下面列出了全部可用的future语句，关注2/3兼容性的开发者都应该知道。

• division：Python 3新增的除法运算符（PEP 238）。

• absolute_import：将全部不以点字符开头的import语句格式解释为绝对导入（PEP 328）。

• print_function：将print语句变为函数调用，因此在print后面必须加括号（PEP 3112）。

• unicode_literals：将每一个字符串解释为Unicode（PEP 3112）。

future中的可选语句列表很短，只包含几个语法功能。对于其余变化的内容，例如元类语法（第3章会讲到这一高级特性），维持其兼容性则困可贵多。future语句也没法彻底解决多个标准库重组的问题。幸运的是，有些工具旨在提供一致可用的兼容层。最有名的就是Six模块，提供了经常使用的2/3兼容性的整个样板。另外一个颇有前途但名气稍逊的工具是future模块。

在某些状况下，开发人员可能不想在一些小型Python包里添加其余依赖项。一般的作法是将全部兼容性代码放在一个附加模块中，该模块一般命名为compat.py。下面是来自python-gmaps项目的compat模块实例：

 # -- coding: utf-8 -*- import sys if sys.version_info < (3, 0, 0): import urlparse # noqa def is_string(s): return isinstance(s, basestring) else: from urllib import parse as urlparse # noqa def is_string(s): return isinstance(s, str)

这样的compat.py模块十分常见，即便是利用Six保持2/3兼容性的项目也很常见，由于这种方法很是方便，用于保存在不一样版本的依赖包之间保持兼容性的代码。

　

下载示例代码

你能够用本身的帐号在Packt的官方网站下载本书的示例代码文件。若是你是在其余地方购买的本书，你能够访问Packt的官方网站并注册，文件会直接经过邮件发送给你。

下载代码文件的步骤以下。

• 用你的电子邮件地址和密码登陆或注册咱们的网站。

• 将鼠标指针悬停在顶部的SUPPORT选项卡上。

• 单击Code Downloads & Errata。

• 在Search框中输入本书的名字。

• 选择你要下载代码文件的书籍。

• 从下拉菜单中选择本书的购买途径。

• 单击Code Download。

文件下载完成后，请确保用下列软件的最新版本对文件夹进行解压或提取。

• 在Windows上用WinRAR或7-Zip。

• 在Mac上用Zipeg、iZip或UnRarX。

• 在Linux上用7-Zip或PeaZip。

本书的代码包也托管在GitHub，网址为github.com/ PacktPublishing/Expert-Python-Programming_Second- Edition。在GitHub上还有大量图书和视频资源。去看一下吧！

1.6Python从入门到放弃

Python大全都在这儿了

本文摘自《Python高级编程（第2版）》

    

Python高级编程（第2版）        

更多python好书  

www.epubit.com.cn/search?q=py…

图像说明文字