python达

其实在糖糖看来好的程序员不是天生就是有这方面的天赋，像那些技术大牛的技能提升都是经过不断的阅读书籍、编写程序、在不断的调试中提升自己的，所以搜集一些质量比较好的书籍是非常有必要的。今天糖糖就给大家推荐几本学习python比较有价值的书籍。如果小伙伴感觉有帮助的话可以多多点赞哦！

1、2017年，新增《Python编程 从入门到实践》从基本概念到完整项目开发，帮助零基础读者迅速掌握Python编程 上到有编程基础的程序员，下到10岁少年，想入门Python并达到可以开发实际项目的水平，本书是最佳选择！

2、《像计算机科学家一样思考Python》全书贯穿的主体是如何思考、设计、开发的方法，而具体的编程语言，只是提供一个具体场景方便介绍的媒介。不是一本介绍语言的书，而是一本介绍编程思想的书。

3、《Python 核心编程第二版》（重点推荐）Python核心编程（第二版）是一本python基础教程指南，python核心编程实例指导，对wxpython数据库充分的讲解，不可错过的编程实践宝典！ 在第一版的基础上进行了全面升级。

4、《Python Web开发 测试驱动方法》（重点推荐）主要从最基础的知识开始，讲解Web开发的整个流程，展示如何使用Python做测试驱动开发。

5、《Python 参考手册》python 编程语言的权威参考指南，书中详尽解释了python 核心语言和python 库中最重要的部分，涉及类型和对象、操作符和表达式、编程结构和控制流、输入和输出、测试、调试等。

6、《Python学习手册》学习Python编程语言的入门书籍。

7、《Python cookbook》Python应用在各个领域中的一些使用技巧和方法，从最基本的字符、文件序列、字典和排序，到进阶的面向对象编程、数据库和数据持久化、 XML处理和Web编程，再到比较高级和抽象的描述符、装饰器、元类、迭代器和生成器，均有涉及。

糖糖推荐的几本书有重点推荐的都有标注哦，不过对于咱们python程序员来说还是要自己实践中才能得到更好的进步。

你们那里的大牛都是再看什么书呢，可以帮助糖糖补充建议呢。不看书的程序员不是好程序员，作为好程序员看书是必不可少的事儿！

大数据文摘作品，转载要求见文末

作者 | Adam Geitgey

编译 | 元元、Lisa、Saint、Aileen

原文链接 | https://medium/@ageitgey/quick-tip-speed-up-your-python-data-processing-scripts-with-process-pools-cf275350163a

Python绝对是处理数据或者把重复任务自动化的绝佳编程语言。要抓取网页日志?或者要调整一百万张图片？总有对应的Python库让你轻松完成任务。

然而，Python的运营速度一直饱受诟病。默认状态下，Python程序使用单个CPU的单个进程。如果你的电脑是最近十年生产的，多数情况下会有4个及以上CPU核。也就是说，当你在等程序运行结束的时候，你的计算机有75%或者更多的计算资源都是空置的！

让我们来看看如何通过并行运算充分利用计算资源。多亏有Python的concurrent.futures模块，仅需3行代码就可以让一个普通程序并行运行。

一般情况下的Python运行

比如说我们有一个文件夹，里面全是图片文件，我们想给每一张图片创建缩略图。

下面的短程序中我们使用Python自带的glob 函数获取一个包含文件夹中所有图片文件的列表，并用Pillow图片处理库获取每张图片的128像素缩略图。

这个程序遵循很常见的数据处理模式：

1. 从您想处理的一系列文件（或其他数据）开始

2. 编写一个处理一个数据的辅助函数

3. 用for循环调动辅助函数，一个一个的去处理数据

让我们用1000张图片来测试这个程序，看看运行时间是多少。

程序运行时间8.9秒，但是计算机的运算资源占用了多少呢？

让我们再跑一次程序，同时查看活动监视器：

计算机有75%空置，这是为什么呢？

问题在于我的计算机有4个CPU核，但是Python只用了其中一个核。即便我的程序把那个CPU核完全占满，但是其他3个CPU核什么也没干。我们需要想办法把整个程序的工作量分成4份然后平行运行。所幸Python可以做到这一点！

让我们来试试并行运算

下面是实现并行运算的一个方法：

1.把Jpeg图片文件列表分成4个部分。

2. 同时跑四个Python解释器。

3. 让四个解释器分别处理一部分图片文件。

4. 汇总四个解释器的结果得到最终结果。

四个Python程序分别在4个CPU上运行，跟之前在1个CPU运行相比大概可以达到4倍的速度，对不对？

好消息是Python可以帮我们解决并行运算麻烦的部分。我们仅需要告诉 Python我们想要运行什么函数以及我们希望工作分成多少份，其他部分留给Python。我们只需要修改三行代码。

首先，我们需要导入concurrent.futures库。这个库是Python自带的：

然后，我们需要告诉 Python另外启动4个Python实例。我们通过创建Process Pool来传达指令：

默认设置下，上面的代码会给计算机的每一个CPU创建一个Python进程，所以如果您的计算机有4个CPU，就会开启4个Python进程。

最后一步是让Process Pool 用这4个进程在数据列表中执行我们的辅助函数。我们可以把我们之前的for循环替代为：

新代码是调用executor.map()函数

executor.map() 函数调用时需要输入辅助函数和待处理的数据列表。这个函数帮我们完成所有麻烦的工作，把列表分成几个小列表，把小列表分配给每个子进程，运行子进程，以及汇总结果。干得漂亮！

我们也可以得到每次调用辅助函数的结果。executor.map()函数以输入数据顺序返回结果。 Python的zip()函数可以一步获取原始文件名以及相应结果。

下面是经过三步改动之后的程序：

让我们试着运行一下，看看有没有缩短运行时间：

2.274秒程序就运行完了！这便是原来版本的4倍加速。运行时间缩短的原因正是我们这次用4个CPU代替了1个CPU。

但是如果您仔细看看，您会看到“用户(User)”时间大概是接近9秒，如果程序2秒就运行结束了，为什么客户时间会是9秒？这似乎…有哪里不对？

其实这是因为”用户”时间是所有CPU时间的总和。我们和上次一样，用9秒的总CPU

注意：启用Python进程以及给子进程分配数据都会占用时间，因此您不一定能靠这个方法大幅提高速度。如果您处理的数据量很大，这里有一篇“设置chunksize参数的技巧”文章可能可以帮助您：https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Executor.map。

这种方法总能帮我的程序提速吗？

当你有一列数据，并且每个数据都可以独立处理的时候，使用Process Pools是一个好方法。这有一些适合使用并行处理的例子：

从一系列单独的网页服务器日志里抓取数据。

从一堆XML，CSV和JSON文件中解析数据。

对大量图片数据做预处理，建立机器学习数据集。

但Process Pools不是万能的。使用Process Pool需要在独立的Python处理过程中将数据来回传递。如果你正在使用的数据不能在处理过程中有效的被传递，这种方法就行不通。你处理的数据必须是Python知道怎么搞定的类型（https://docs.python.org/3/library/pickle.html#what-can-be-pickled-and-unpickled）。

同时，数据不会按照一个预想的顺序被处理。如果你需要前一步的处理结果来进行下一步骤，这种方法也行不通。

那GIL怎么办？

你可能听说过Python有一个全局解释器锁（Global Interpreter Lock,），缩写为GIL。这意味着即使你的程序是多层的，每一层也只有一个Python命令能被执行。GIL确保任何时候都只有一个Python线程执行。 GIL最大的问题就是Python的多线程程序并不能利用多核CPU的优势。

但Process Pools能解决这个问题！因为我们在运行单独的Python实例，每个实例都有自己的GIL。这样你就有了真正的并行处理的Python代码！

不要害怕并行处理！

有了concurrent.futures库，Python可以让你简简单单地修改脚本，却能立刻调用你电脑上所有CPU内核开足马力地运行。不要害怕尝试。一旦你会用了，它就像写一个for循环那样简单，但会让整个程序快很多。

点击上方“CSDN”，选择“置顶公众号”

关键时刻，第一时间送达！

以前我常常说（虽然现在看法不同了）：

从另外一个角度说，我发现现实世界中很多“性能”问题往往是由CPython解释器速度之外的因素引起的。没错，我希望解释器能快一些，但以我的经验看来，很多其他因素才是最主要的。至少，我们可以先从这些因素上想办法。但是关于性能的讨论却很少提到其他非常重要且值得考虑的因素，比如说开发者的效率和编程经验。这一点往往被低估，其实非常不应该！摩尔定律对人类并不适用，向项目中投入人手并不能有效地提高产出，也不能成比例地提高产出。Python是最好的开发语言和生态环境之一，其开发过程非常有趣，品质非常高，而且很有效率。

我以前一直认为，为提高效率而付出额外的努力部分原因是功利主义编程的表现。比如，额外花50个小时写一段代码，只为了让运行速度加快了1分钟，这是得不偿失的，除非这段代码会运行3000次以上。而在数据分析中很少有这种情况。现在我对这个问题的看法没有以前那么极端了。现在我认为CPython（唯一被广泛使用的Python解释器）很慢的事实是这个语言主要的劣势，并不是为了提高开发速度而付出的微小代价。

是什么让我改变了看法？

首先，我工作的内容变了。以前我的很多工作可以轻松地写成numpy的操作（numpy使用编译好的代码，所以速度很快），现在我写的很多代码与数值没有关系。其次，如果我必须使用标准的Python写代码的话，那么代码会慢得像乌龟爬。我的意思不是说“等几秒”的慢，而是说“两分钟的事情慢到需要等几个小时。”

同时，数据量越来越大，而计算机的核心（可惜Python没法简单地利用多核）也越来越多，但单个核心的性能提升却非常缓慢。所以，从性能方面来说，Python是越来越差的选择。

其他语言在运行高级代码时（使用JIT或激进的编译时优化），也能展现良好的性能。从旁观者的角度看来，Python的核心开发团队似乎对性能问题并不感兴趣。他们开展了许多优化的项目，如psyco、 unladen swallow、 stackless、 shedskin、pypy等，但只有最后一个项目处于积极的开发中。但是，尽管他们忙来忙去，这些成果却从来没能应用到CPython，以致于CPython还在沿用20年前的字节码堆栈机的策略。虽说优化一个非常动态的语言必须谨慎行事，但是Javascript也和Python一样是动态的，已经有几个基于JIT的实现了。

程序员的时间比计算机的时间更有价值，这话虽然没错，但是等待计算结果也是浪费我的时间。虽然我觉得我可以在等待期间做点别的事情，但是切换思路让我很头疼，所以我宁愿等待。

有时我还发现，为了让Python运行的程序快点，我经常会写一些十分复杂的代码，几乎没法读。比如这个函数（https://git.embl.de/costea/metaSNV/blob/master/metaSNV_post.py#L331）。第一次我们写了一个循环函数，直接引用计算公式。结果运行时间与中型（所谓中型指的是需要花费几周时间运行的问题）问题的运行时间差不多。现在，这个函数的运行减少到了几秒钟，但是除非你远比我聪明，否则要读懂代码中蕴含的公式可不是简单的事情。

结果我发现自己用Haskell做的东西越来越多，用Haskell可以写出性能良好（虽然性能还是不如C++，但是Haskell有很多很好的库）的高级代码。我还用Jug（基于Python）做连接，但是在运行中它会调用Haskell的代码完成功能。

现在有时我用Python创建原型，然后开始比赛：我在主数据集上运行分析，同时用Haskell重新实现整个功能。然后我运行Haskell版本，尽力在Python分析之前运行完毕。好多次，都是Haskell版本获胜（加上开发时间！）。

有天我遇到了一个很“有趣”的Python性能bug：删除10亿条字符串需要花费的时间超过12个小时。很显然这种情况可以解决，但是放在几年前，我肯定束手无策。以前10亿条字符串算是很多了，但现在我们感觉几TB的数据也“没什么大不了”。你可能没有遇到这样的事情，但是至少我是这样的。而且根据我在hackernews上的评论，我可以总结观点如下：

我主要的目的是为了节约总体花费时间，包括写代码的时间+运行代码的时间。

Python写代码的时间非常短，但是运行代码的时间却非常长。写代码的时间是人为因素（除了初学时的学习曲线外，我无法再有所提高）不计入内。但是一方面数据集越来越大，另一方面单个核心的性能又无法得到改善的情况下，运行代码的时间在不断增长，所以越来越值得花费更多时间优化代码，从而降低运行代码的时间。C++可以提供最短的运行代码时间，但是写代码的时间却太长（因为缺乏优秀的代码库和包管理）。所以至少对我来说Haskell是最好的选择。

上述方法适用于我的工作，因为我们使用大数据集作为输入，不过你的情况可能会有所不同。

此外针对以上的讨论，下面择取了hackernews上的部分观点，供大家参考。

观点一：文章讨论的是：Python的性能是否有问题？答案很显然：“有时会有问题，但你可以有别的选择。”

作者正是遇到了“有时”的情况，并且做出了自己的选择。你用Python做原型，并做连接，同时采用Haskell提高性能。这样的选择是很明智的。我觉得没有Python的粉丝会说Python适合任何情况下的任何工作。我们通常会说，Python是每项工作的“首选”。用Python创建的系统，可以很快让你看到结果，从而判断仅采用Python是否足够。

观点二：我认为，性能永远很重要，而Python绝不是最好的工具。

就目前的环境来说，Python也许是正确的选择，但并不是说不存在可以与Python媲美同时还能提供良好性能的语言。比如像Nim或F#这些语言已经很接近了。而且，当我知道Python也有高性能的衍生版本时，我认为它们应该成为主要标准，而且是唯一的标准。速度缓慢的版本不应该再存在。我们的社区让速度慢的语言蓬勃发展是个巨大的错误，因为慢速工具流行意味着编程的速度也很慢，进一步浪费了他人的时间和精力。另一个例子是Electron已成为了跨平台桌面应用的标准。为特定目的选择Electron固然没错，但软件社区允许这种毫无性能可言的东西发展成为最佳选择却是个错误。不要再说“不喜欢慢的软件，你可以不用啊”，因为许多东西已成为事实上的标准，你无处躲避。公司可能要求使用Microsoft Teams作为交流工具，你就不得不仅仅为发几条消息而耗费大量的内存和电池。越来越多的人愿意为Atom开发语言插件，所以在选择优秀的IDE时，Atom就成了唯一可行的选择，于是你不得不忍受它的性能。

原文地址：https://metarabbit.wordpress/2018/02/05/pythons-weak-performance-matters/作者：Luis Pedro Coelho，计算生物学家。2011年卡内基·梅隆大学博士毕业，主要从事亚细胞定位分析等生物图形信息研究、以及大规模图像数据的处理，致力于生物标本图像分析中机器学习技术的应用。他是Python计算机视觉库mahotas的主要开发人员。他于1998年开始开发开源软件，2004年起从事Python开发，并为多个Python开源库贡献了代码。译者：马晶慧

————— 推荐阅读 —————