其實(shí)在糖糖看來好的程序員不是天生就是有這方面的天賦，像那些技術(shù)大牛的技能提升都是經(jīng)過不斷的閱讀書籍、編寫程序、在不斷的調(diào)試中提升自己的，所以搜集一些質(zhì)量比較好的書籍是非常有必要的。今天糖糖就給大家推薦幾本學(xué)習(xí)python比較有價值的書籍。如果小伙伴感覺有幫助的話可以多多點(diǎn)贊哦！

1、2017年，新增《Python編程 從入門到實(shí)踐》從基本概念到完整項(xiàng)目開發(fā)，幫助零基礎(chǔ)讀者迅速掌握Python編程 上到有編程基礎(chǔ)的程序員，下到10歲少年，想入門Python并達(dá)到可以開發(fā)實(shí)際項(xiàng)目的水平，本書是最佳選擇！

2、《像計(jì)算機(jī)科學(xué)家一樣思考Python》全書貫穿的主體是如何思考、設(shè)計(jì)、開發(fā)的方法，而具體的編程語言，只是提供一個具體場景方便介紹的媒介。不是一本介紹語言的書，而是一本介紹編程思想的書。

3、《Python 核心編程第二版》（重點(diǎn)推薦）Python核心編程（第二版）是一本python基礎(chǔ)教程指南，python核心編程實(shí)例指導(dǎo)，對wxpython數(shù)據(jù)庫充分的講解，不可錯過的編程實(shí)踐寶典！ 在第一版的基礎(chǔ)上進(jìn)行了全面升級。

4、《Python Web開發(fā) 測試驅(qū)動方法》（重點(diǎn)推薦）主要從最基礎(chǔ)的知識開始，講解Web開發(fā)的整個流程，展示如何使用Python做測試驅(qū)動開發(fā)。

5、《Python 參考手冊》python 編程語言的權(quán)威參考指南，書中詳盡解釋了python 核心語言和python 庫中最重要的部分，涉及類型和對象、操作符和表達(dá)式、編程結(jié)構(gòu)和控制流、輸入和輸出、測試、調(diào)試等。

6、《Python學(xué)習(xí)手冊》學(xué)習(xí)Python編程語言的入門書籍。

7、《Python cookbook》Python應(yīng)用在各個領(lǐng)域中的一些使用技巧和方法，從最基本的字符、文件序列、字典和排序，到進(jìn)階的面向?qū)ο缶幊?、?shù)據(jù)庫和數(shù)據(jù)持久化、 XML處理和Web編程，再到比較高級和抽象的描述符、裝飾器、元類、迭代器和生成器，均有涉及。

糖糖推薦的幾本書有重點(diǎn)推薦的都有標(biāo)注哦，不過對于咱們python程序員來說還是要自己實(shí)踐中才能得到更好的進(jìn)步。

你們那里的大牛都是再看什么書呢，可以幫助糖糖補(bǔ)充建議呢。不看書的程序員不是好程序員，作為好程序員看書是必不可少的事兒！

大數(shù)據(jù)文摘作品，轉(zhuǎn)載要求見文末

作者 | Adam Geitgey

編譯 | 元元、Lisa、Saint、Aileen

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

Python絕對是處理數(shù)據(jù)或者把重復(fù)任務(wù)自動化的絕佳編程語言。要抓取網(wǎng)頁日志?或者要調(diào)整一百萬張圖片？總有對應(yīng)的Python庫讓你輕松完成任務(wù)。

然而，Python的運(yùn)營速度一直飽受詬病。默認(rèn)狀態(tài)下，Python程序使用單個CPU的單個進(jìn)程。如果你的電腦是最近十年生產(chǎn)的，多數(shù)情況下會有4個及以上CPU核。也就是說，當(dāng)你在等程序運(yùn)行結(jié)束的時候，你的計(jì)算機(jī)有75%或者更多的計(jì)算資源都是空置的！

讓我們來看看如何通過并行運(yùn)算充分利用計(jì)算資源。多虧有Python的concurrent.futures模塊，僅需3行代碼就可以讓一個普通程序并行運(yùn)行。

一般情況下的Python運(yùn)行

比如說我們有一個文件夾，里面全是圖片文件，我們想給每一張圖片創(chuàng)建縮略圖。

下面的短程序中我們使用Python自帶的glob 函數(shù)獲取一個包含文件夾中所有圖片文件的列表，并用Pillow圖片處理庫獲取每張圖片的128像素縮略圖。

這個程序遵循很常見的數(shù)據(jù)處理模式：

1. 從您想處理的一系列文件（或其他數(shù)據(jù)）開始

2. 編寫一個處理一個數(shù)據(jù)的輔助函數(shù)

3. 用for循環(huán)調(diào)動輔助函數(shù)，一個一個的去處理數(shù)據(jù)

讓我們用1000張圖片來測試這個程序，看看運(yùn)行時間是多少。

程序運(yùn)行時間8.9秒，但是計(jì)算機(jī)的運(yùn)算資源占用了多少呢？

讓我們再跑一次程序，同時查看活動監(jiān)視器：

計(jì)算機(jī)有75%空置，這是為什么呢？

問題在于我的計(jì)算機(jī)有4個CPU核，但是Python只用了其中一個核。即便我的程序把那個CPU核完全占滿，但是其他3個CPU核什么也沒干。我們需要想辦法把整個程序的工作量分成4份然后平行運(yùn)行。所幸Python可以做到這一點(diǎn)！

讓我們來試試并行運(yùn)算

下面是實(shí)現(xiàn)并行運(yùn)算的一個方法：

1.把Jpeg圖片文件列表分成4個部分。

2. 同時跑四個Python解釋器。

3. 讓四個解釋器分別處理一部分圖片文件。

4. 匯總四個解釋器的結(jié)果得到最終結(jié)果。

四個Python程序分別在4個CPU上運(yùn)行，跟之前在1個CPU運(yùn)行相比大概可以達(dá)到4倍的速度，對不對？

好消息是Python可以幫我們解決并行運(yùn)算麻煩的部分。我們僅需要告訴 Python我們想要運(yùn)行什么函數(shù)以及我們希望工作分成多少份，其他部分留給Python。我們只需要修改三行代碼。

首先，我們需要導(dǎo)入concurrent.futures庫。這個庫是Python自帶的：

然后，我們需要告訴 Python另外啟動4個Python實(shí)例。我們通過創(chuàng)建Process Pool來傳達(dá)指令：

默認(rèn)設(shè)置下，上面的代碼會給計(jì)算機(jī)的每一個CPU創(chuàng)建一個Python進(jìn)程，所以如果您的計(jì)算機(jī)有4個CPU，就會開啟4個Python進(jìn)程。

最后一步是讓Process Pool 用這4個進(jìn)程在數(shù)據(jù)列表中執(zhí)行我們的輔助函數(shù)。我們可以把我們之前的for循環(huán)替代為：

新代碼是調(diào)用executor.map()函數(shù)

executor.map() 函數(shù)調(diào)用時需要輸入輔助函數(shù)和待處理的數(shù)據(jù)列表。這個函數(shù)幫我們完成所有麻煩的工作，把列表分成幾個小列表，把小列表分配給每個子進(jìn)程，運(yùn)行子進(jìn)程，以及匯總結(jié)果。干得漂亮！

我們也可以得到每次調(diào)用輔助函數(shù)的結(jié)果。executor.map()函數(shù)以輸入數(shù)據(jù)順序返回結(jié)果。 Python的zip()函數(shù)可以一步獲取原始文件名以及相應(yīng)結(jié)果。

下面是經(jīng)過三步改動之后的程序：

讓我們試著運(yùn)行一下，看看有沒有縮短運(yùn)行時間：

2.274秒程序就運(yùn)行完了！這便是原來版本的4倍加速。運(yùn)行時間縮短的原因正是我們這次用4個CPU代替了1個CPU。

但是如果您仔細(xì)看看，您會看到“用戶(User)”時間大概是接近9秒，如果程序2秒就運(yùn)行結(jié)束了，為什么客戶時間會是9秒？這似乎…有哪里不對？

其實(shí)這是因?yàn)椤庇脩簟睍r間是所有CPU時間的總和。我們和上次一樣，用9秒的總CPU

注意：啟用Python進(jìn)程以及給子進(jìn)程分配數(shù)據(jù)都會占用時間，因此您不一定能靠這個方法大幅提高速度。如果您處理的數(shù)據(jù)量很大，這里有一篇“設(shè)置chunksize參數(shù)的技巧”文章可能可以幫助您：https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Executor.map。

這種方法總能幫我的程序提速嗎？

當(dāng)你有一列數(shù)據(jù)，并且每個數(shù)據(jù)都可以獨(dú)立處理的時候，使用Process Pools是一個好方法。這有一些適合使用并行處理的例子：

從一系列單獨(dú)的網(wǎng)頁服務(wù)器日志里抓取數(shù)據(jù)。

從一堆XML，CSV和JSON文件中解析數(shù)據(jù)。

對大量圖片數(shù)據(jù)做預(yù)處理，建立機(jī)器學(xué)習(xí)數(shù)據(jù)集。

但Process Pools不是萬能的。使用Process Pool需要在獨(dú)立的Python處理過程中將數(shù)據(jù)來回傳遞。如果你正在使用的數(shù)據(jù)不能在處理過程中有效的被傳遞，這種方法就行不通。你處理的數(shù)據(jù)必須是Python知道怎么搞定的類型（https://docs.python.org/3/library/pickle.html#what-can-be-pickled-and-unpickled）。

同時，數(shù)據(jù)不會按照一個預(yù)想的順序被處理。如果你需要前一步的處理結(jié)果來進(jìn)行下一步驟，這種方法也行不通。

那GIL怎么辦？

你可能聽說過Python有一個全局解釋器鎖（Global Interpreter Lock,），縮寫為GIL。這意味著即使你的程序是多層的，每一層也只有一個Python命令能被執(zhí)行。GIL確保任何時候都只有一個Python線程執(zhí)行。 GIL最大的問題就是Python的多線程程序并不能利用多核CPU的優(yōu)勢。

但Process Pools能解決這個問題！因?yàn)槲覀冊谶\(yùn)行單獨(dú)的Python實(shí)例，每個實(shí)例都有自己的GIL。這樣你就有了真正的并行處理的Python代碼！

不要害怕并行處理！

有了concurrent.futures庫，Python可以讓你簡簡單單地修改腳本，卻能立刻調(diào)用你電腦上所有CPU內(nèi)核開足馬力地運(yùn)行。不要害怕嘗試。一旦你會用了，它就像寫一個for循環(huán)那樣簡單，但會讓整個程序快很多。

點(diǎn)擊上方“CSDN”，選擇“置頂公眾號”

關(guān)鍵時刻，第一時間送達(dá)！

以前我常常說（雖然現(xiàn)在看法不同了）：

從另外一個角度說，我發(fā)現(xiàn)現(xiàn)實(shí)世界中很多“性能”問題往往是由CPython解釋器速度之外的因素引起的。沒錯，我希望解釋器能快一些，但以我的經(jīng)驗(yàn)看來，很多其他因素才是最主要的。至少，我們可以先從這些因素上想辦法。但是關(guān)于性能的討論卻很少提到其他非常重要且值得考慮的因素，比如說開發(fā)者的效率和編程經(jīng)驗(yàn)。這一點(diǎn)往往被低估，其實(shí)非常不應(yīng)該！摩爾定律對人類并不適用，向項(xiàng)目中投入人手并不能有效地提高產(chǎn)出，也不能成比例地提高產(chǎn)出。Python是最好的開發(fā)語言和生態(tài)環(huán)境之一，其開發(fā)過程非常有趣，品質(zhì)非常高，而且很有效率。

我以前一直認(rèn)為，為提高效率而付出額外的努力部分原因是功利主義編程的表現(xiàn)。比如，額外花50個小時寫一段代碼，只為了讓運(yùn)行速度加快了1分鐘，這是得不償失的，除非這段代碼會運(yùn)行3000次以上。而在數(shù)據(jù)分析中很少有這種情況?，F(xiàn)在我對這個問題的看法沒有以前那么極端了?，F(xiàn)在我認(rèn)為CPython（唯一被廣泛使用的Python解釋器）很慢的事實(shí)是這個語言主要的劣勢，并不是為了提高開發(fā)速度而付出的微小代價。

是什么讓我改變了看法？

首先，我工作的內(nèi)容變了。以前我的很多工作可以輕松地寫成numpy的操作（numpy使用編譯好的代碼，所以速度很快），現(xiàn)在我寫的很多代碼與數(shù)值沒有關(guān)系。其次，如果我必須使用標(biāo)準(zhǔn)的Python寫代碼的話，那么代碼會慢得像烏龜爬。我的意思不是說“等幾秒”的慢，而是說“兩分鐘的事情慢到需要等幾個小時?！?/p>

同時，數(shù)據(jù)量越來越大，而計(jì)算機(jī)的核心（可惜Python沒法簡單地利用多核）也越來越多，但單個核心的性能提升卻非常緩慢。所以，從性能方面來說，Python是越來越差的選擇。

其他語言在運(yùn)行高級代碼時（使用JIT或激進(jìn)的編譯時優(yōu)化），也能展現(xiàn)良好的性能。從旁觀者的角度看來，Python的核心開發(fā)團(tuán)隊(duì)似乎對性能問題并不感興趣。他們開展了許多優(yōu)化的項(xiàng)目，如psyco、 unladen swallow、 stackless、 shedskin、pypy等，但只有最后一個項(xiàng)目處于積極的開發(fā)中。但是，盡管他們忙來忙去，這些成果卻從來沒能應(yīng)用到CPython，以致于CPython還在沿用20年前的字節(jié)碼堆棧機(jī)的策略。雖說優(yōu)化一個非常動態(tài)的語言必須謹(jǐn)慎行事，但是Javascript也和Python一樣是動態(tài)的，已經(jīng)有幾個基于JIT的實(shí)現(xiàn)了。

程序員的時間比計(jì)算機(jī)的時間更有價值，這話雖然沒錯，但是等待計(jì)算結(jié)果也是浪費(fèi)我的時間。雖然我覺得我可以在等待期間做點(diǎn)別的事情，但是切換思路讓我很頭疼，所以我寧愿等待。

有時我還發(fā)現(xiàn)，為了讓Python運(yùn)行的程序快點(diǎn)，我經(jīng)常會寫一些十分復(fù)雜的代碼，幾乎沒法讀。比如這個函數(shù)（https://git.embl.de/costea/metaSNV/blob/master/metaSNV_post.py#L331）。第一次我們寫了一個循環(huán)函數(shù)，直接引用計(jì)算公式。結(jié)果運(yùn)行時間與中型（所謂中型指的是需要花費(fèi)幾周時間運(yùn)行的問題）問題的運(yùn)行時間差不多?，F(xiàn)在，這個函數(shù)的運(yùn)行減少到了幾秒鐘，但是除非你遠(yuǎn)比我聰明，否則要讀懂代碼中蘊(yùn)含的公式可不是簡單的事情。

結(jié)果我發(fā)現(xiàn)自己用Haskell做的東西越來越多，用Haskell可以寫出性能良好（雖然性能還是不如C++，但是Haskell有很多很好的庫）的高級代碼。我還用Jug（基于Python）做連接，但是在運(yùn)行中它會調(diào)用Haskell的代碼完成功能。

現(xiàn)在有時我用Python創(chuàng)建原型，然后開始比賽：我在主數(shù)據(jù)集上運(yùn)行分析，同時用Haskell重新實(shí)現(xiàn)整個功能。然后我運(yùn)行Haskell版本，盡力在Python分析之前運(yùn)行完畢。好多次，都是Haskell版本獲勝（加上開發(fā)時間?。?。

有天我遇到了一個很“有趣”的Python性能bug：刪除10億條字符串需要花費(fèi)的時間超過12個小時。很顯然這種情況可以解決，但是放在幾年前，我肯定束手無策。以前10億條字符串算是很多了，但現(xiàn)在我們感覺幾TB的數(shù)據(jù)也“沒什么大不了”。你可能沒有遇到這樣的事情，但是至少我是這樣的。而且根據(jù)我在hackernews上的評論，我可以總結(jié)觀點(diǎn)如下：

我主要的目的是為了節(jié)約總體花費(fèi)時間，包括寫代碼的時間+運(yùn)行代碼的時間。

Python寫代碼的時間非常短，但是運(yùn)行代碼的時間卻非常長。寫代碼的時間是人為因素（除了初學(xué)時的學(xué)習(xí)曲線外，我無法再有所提高）不計(jì)入內(nèi)。但是一方面數(shù)據(jù)集越來越大，另一方面單個核心的性能又無法得到改善的情況下，運(yùn)行代碼的時間在不斷增長，所以越來越值得花費(fèi)更多時間優(yōu)化代碼，從而降低運(yùn)行代碼的時間。C++可以提供最短的運(yùn)行代碼時間，但是寫代碼的時間卻太長（因?yàn)槿狈?yōu)秀的代碼庫和包管理）。所以至少對我來說Haskell是最好的選擇。

上述方法適用于我的工作，因?yàn)槲覀兪褂么髷?shù)據(jù)集作為輸入，不過你的情況可能會有所不同。

此外針對以上的討論，下面擇取了hackernews上的部分觀點(diǎn)，供大家參考。

觀點(diǎn)一：文章討論的是：Python的性能是否有問題？答案很顯然：“有時會有問題，但你可以有別的選擇?！?/p>

作者正是遇到了“有時”的情況，并且做出了自己的選擇。你用Python做原型，并做連接，同時采用Haskell提高性能。這樣的選擇是很明智的。我覺得沒有Python的粉絲會說Python適合任何情況下的任何工作。我們通常會說，Python是每項(xiàng)工作的“首選”。用Python創(chuàng)建的系統(tǒng)，可以很快讓你看到結(jié)果，從而判斷僅采用Python是否足夠。

觀點(diǎn)二：我認(rèn)為，性能永遠(yuǎn)很重要，而Python絕不是最好的工具。

就目前的環(huán)境來說，Python也許是正確的選擇，但并不是說不存在可以與Python媲美同時還能提供良好性能的語言。比如像Nim或F#這些語言已經(jīng)很接近了。而且，當(dāng)我知道Python也有高性能的衍生版本時，我認(rèn)為它們應(yīng)該成為主要標(biāo)準(zhǔn)，而且是唯一的標(biāo)準(zhǔn)。速度緩慢的版本不應(yīng)該再存在。我們的社區(qū)讓速度慢的語言蓬勃發(fā)展是個巨大的錯誤，因?yàn)槁俟ぞ吡餍幸馕吨幊痰乃俣纫埠苈?，進(jìn)一步浪費(fèi)了他人的時間和精力。另一個例子是Electron已成為了跨平臺桌面應(yīng)用的標(biāo)準(zhǔn)。為特定目的選擇Electron固然沒錯，但軟件社區(qū)允許這種毫無性能可言的東西發(fā)展成為最佳選擇卻是個錯誤。不要再說“不喜歡慢的軟件，你可以不用啊”，因?yàn)樵S多東西已成為事實(shí)上的標(biāo)準(zhǔn)，你無處躲避。公司可能要求使用Microsoft Teams作為交流工具，你就不得不僅僅為發(fā)幾條消息而耗費(fèi)大量的內(nèi)存和電池。越來越多的人愿意為Atom開發(fā)語言插件，所以在選擇優(yōu)秀的IDE時，Atom就成了唯一可行的選擇，于是你不得不忍受它的性能。

原文地址：https://metarabbit.wordpress/2018/02/05/pythons-weak-performance-matters/作者：Luis Pedro Coelho，計(jì)算生物學(xué)家。2011年卡內(nèi)基·梅隆大學(xué)博士畢業(yè)，主要從事亞細(xì)胞定位分析等生物圖形信息研究、以及大規(guī)模圖像數(shù)據(jù)的處理，致力于生物標(biāo)本圖像分析中機(jī)器學(xué)習(xí)技術(shù)的應(yīng)用。他是Python計(jì)算機(jī)視覺庫mahotas的主要開發(fā)人員。他于1998年開始開發(fā)開源軟件，2004年起從事Python開發(fā)，并為多個Python開源庫貢獻(xiàn)了代碼。譯者：馬晶慧

————— 推薦閱讀 —————