如何深入了解python原理？

01-23

目前用requests庫寫過帶cookies和驗證碼識別的多線程爬蟲，也用flask寫過伺服器端，numpy、pandas處理數據這類也做過，學過coursera上的機器學習課程（華盛頓大學用python的那個，目前只學完了fundamental和regression部分），但是前幾天看了一篇文章（下圖是其中一部分）
發現還是有幾個不知道的啊（比如2），請問各位大神這可怎麼破，怎麼深入了解一下python的原理?

1，你曾經用python做過大工程，簡歷寫精通python，面試官會說你得了解python各種__xxx__實現細節才算深入了解

2，等你了解了這些python層面的，簡歷寫精通python，面試官會問你python long怎麼實現的，會說你得知道python實現原理

3，你把python源碼剖析看了一遍，簡歷寫精通python，面試官會問你些沒寫過python c binding，都有哪些方法

4，等你把這些都折騰熟了，簡歷寫精通python，面試你可以返樸歸真，找一個他們熟悉的庫，比如tornado問你read_until_XXX怎麼實現的

再往後，只要你寫精通python，只要你碰到一個喜歡攻擊弱點的面試官，你永遠會完敗

所以，簡歷就寫「技能：python」，重點多寫做過什麼，如果問題不是圍繞你的工作展開的，你就可以把面試官pass了，畢竟可能你被錄也不會爽，找工作找得不是簡單的好壞，是matching

PS：我可不是慫恿大家半瓶子醋就自得自滿啊，任何學習就講究博大一片，精深一點，自己得找准自己的方向，不要被其他人帶著走，別到時候你對python的每個字母都知道拉丁來源，你項目產出還是根毛，這樣的python技能掌握了還不是毛用沒有，一切以「解決問題」為著眼點

PS2: 問題中的問題，確實是用python應該了解學會的

想把一個人考倒很容易

想做一個好東西不容易

多學不如多用

這就好像在說除非你把英語語法書給全文背誦下來，你不能聲稱自己會英語一樣。了解這些細節當然有用，但解決問題還是要case-by-case。所以，最後的關鍵是看你要解決什麼問題，寫一個一次性腳本，用個int還要盤算這個int到底有沒有在smallint的範圍之內，只能說是閑得慌。

這種腦殘文理會他們幹什麼。以前是噴精通，現在是連會都不讓說了啊。職位要求里寫著要會Python，難道我簡歷里應該寫不會，我是不是傻？

按他們的思路延伸下去，估計不知道怎麼用END_FINALLY實現GOSUB，都是Python新手。不過，要是真的都像他們說的這樣，不能說都不好，也有一個好的，比如C++就沒人敢用了。所以，他們僅僅是嘴巴上說說而已，不過是把及格線緊緊劃在自己身後，怒斥不如自己的都是新手。畢竟能問出這麼爛的問題的，肯定也是水貨。slice可不一定會copy，不信去看NumPy。

然而可悲的現實是，當下就是這種成功人士當道，整天就會吹噓自己知道這個，知道那個，往往還只知道其一，不知道其二，然而很多公司就喜歡追捧這樣的成功人士。寫程序，不是看你知道的多，知道的少，是看你程序能不能寫出來啊。有些東西，不知道又怎麼了，比如你的程序從來就不需要修改傳進來的參數，不知道9，怎麼了？

程序都寫不出來，知道的再多有啥用，所謂的運行效率高有啥用，程序沒寫出來，你優化的再好，速度也是0啊。既然說實話，大家都不能保證100%比隨便挑出來的一位七歲小朋友先把程序寫出來，何苦相互為難呢？

PSF: 我們（在長時間內訌之後終於達成了共識）好不容易給 3, 4, 6 的情況加了那麼一點微小的優化現在你居然要用它來出題？

記住 Python 的 implementation-dependent behavior 一點都不比 C++ 少。

其實這些問題還好，並不算過分。

至於怎麼看待，取決於你用Python做什麼，怎麼用。如果是拿來寫一些日常工作中的一次性小規模數據處理任務，那麼就像很多回答那樣，根本不用深入了解，更無所謂Pythonic不Pythonic了。

但是如果要做產品級的軟體開發，比如大訪問量、長時間運行的伺服器，那麼這些細節還是有必要熟悉的。比如有一個答案里舉的那個在for range里取下標、字元串累加的做法，這是典型的某些其它語言里合理（比如傳統BASIC）但在Python（以及很多其它語言）里不提倡的做法。如果是我說的第一種場合，這樣寫當然無所謂，但是在第二種場合就要慎重了。很多人喜歡沒事黑一下著名的中國C語言之父譚老師……如果我來黑他，就會用這個例子作為假想中他寫的《高等學校標準教材——Python語言程序設計》中的反模式:p

目測題主寫Python還是以解決日常任務為主吧，應該沒怎麼做過生產環境的Python代碼優化和重構。實際折騰過就熟悉那些細節了。

僅僅是這些的話我覺得還是了解比較好，要麼提前了解，要麼早晚在這裡栽個跟頭，如果你既沒有了解，也沒有栽過跟頭，那就說明工程實踐不夠……

實際上面試的時候不知道就不知道，沒什麼可丟人的，沒接觸過而已，並沒有什麼規定說答不上來面試官的問題就一定不能過，或者答上來了就一定過，如果面試官水平不差，那麼你真實水平是怎樣的，面試的時候體現出來的就是怎樣的，裝也沒用。大部分講面試經的都是為了讓你在自己不足的時候裝，讓面試官誤以為你懂，你裝工程經驗豐富，結果基礎問題都沒弄清，這還怎麼往下裝呢你所對吧。這純粹是應試技巧。

按我說的話，Python的官方文檔，尤其是Language這一章，無論如何都要至少讀一遍，留點印象，起碼以後栽到坑裡的時候知道大致怎麼爬出來。這些內容大部分都在官方文檔當中有非常清楚的詮釋。偏偏許多人不按這個順序來，喜歡看代碼猜語法。

平心而論，這9條都很基礎。中間很多條，我都是實踐中遇到，才明白的。比如第6條，我在一個叫Codeforces的sb網站做題time limit exceeded了，我就來知乎提問了在python里，為什麼p is None比p==None 要快？

我覺得經常寫python的人，這裡大半應當知道才對。1，8面向對象語言基礎知識；第9條悲劇一次，也就明白了。我面試過過一個候選人，他簡歷上寫著『熟練使用python』，他面試的時候居然寫出了這樣幾行代碼：

s = "" for i in range(100): s += a[i] print s

上面說的這些在&

中都提到了, 看完一遍大概都有個印象.

但是吧, 沒在實戰中用到其實那些知識永遠是書本的, 不是自己的. 你看完&

, 你可能知道點原理, 可是一個完全不知道的程序員可以直接上Stack Overflow 上檢索一下, 我相信這些都是熱門問題, 花幾分鐘中看一下大概就懂了. 相比而言, 你們二者的差距並沒有體現出來.

那怎麼把知識內化呢, 還是要多實踐. 項目上不一定每天都可以用到學習的知識, 但是Stack Overflow下有分類很細的標籤, 每當學完一個知識點感覺很牛逼的時候, 去把相應標籤的最高Vote 的問題看一下, 當時基本是蒙蔽的. 然後自己慢慢寫代碼測試, 回答別人的問題. 這樣知識才能成為自己的, 而不是書本上的.

這些都不了解，只能說明工程實踐不夠。裡面很多東西不僅py，對大部分語言都是同樣的，可以推廣的。不僅py實踐不夠，可能唯一會的語言就是py。

另外「會了」一種程序語言其實是個很混淆的概念，不實際了解別人到底「會了」什麼，就扣帽子說人吹牛，也不是什麼好行為。

一個個真不拿20年才能精通c當梗啊。

上面是單純的吐槽。關於題主278點的問題，腳本語言的對象屬性實現，簡單的就是查表，遞歸查表，了解這個就清楚了。了解函數可以傳遞，可以賦給左值，自然也清楚了函數也是值。

看題主舉例做過好多東西，真沒遇到過把函數傳來傳去的情況？

// 驚了，一開始問題說278都不了解，怎麼現在編輯得只剩2不了解了啊？

我把知識分為兩類：道與術。

一門語言，不管包含多少概念，都可以由語言的設計哲學、設計目標和語法一致性（對於設計的比較好的語言而言）串起來。比如圖中羅列的：對象模型、面向對象、可變不可變等，這部分知識是道的層面，這是必須要掌握的，只有掌握了道，你才能做到在實際的開發實踐中對各種「術」的應用自如，因為所有的「術」，都離不開「道」的範疇。學的再深入一些的話，就需要學習語言之道背後的道，那就是操作系統、網路、演算法、數學等基礎知識了。

所以要想深入了解Python的原理，就得往道的層面走。有本書叫《Python源碼剖析》，可以幫助你了解Python內部的實現。通過了解語言的實現，可以提升你對Python的理解。也有很多講Python設計哲學和對象模型的書籍或文章，可以自行搜索。

而僅僅只是會使用別人寫的庫或框架，那還談不上「術」，可以說，那只是搬磚（無貶義，想不到其他的詞來描述了。低水平的人搬高水平的人磚唄，每個人都一樣，但是並不是每個人都抱有學習上進的心）。關於術，那就只能多練了，也可以多看Github上面優秀的Python開源項目。可以參考這個問題的答案：值得看的Python的開源項目有哪些？ - Python 框架 - 知乎

謝邀。

Python 原理？去看python 的實現，如果有c基礎，可以讀一讀 python源碼剖析這本書。

如果是庫，可以直接看源碼啊。

語言層面比較簡單，可以這麼假想：

py簡單說就是box語言，每個對象都放在一個box裡面，box提供一些基礎方法(查看slot函數 magic函數)。

解釋器翻譯源代碼為這些函數的調用組成的位元組碼，然後原子執行。

所有變數都是box的指針/引用，類型就是box工廠。

標準庫層面：多用！注意一下cpython的多線程和gil就行。多線程是模擬分時的，基於系統線程來模擬的，壞處就是解釋器內部的數據會被多線程訪問，這樣就需要加鎖就是gil。自己寫的代碼如果多線程訪問數據也要加鎖，就是多線程的那些同步機制。

我表示看標準真的好累, 我花時間看c++的標準後, 再也提不起精神看其他語言的了

像Python, 我已經完全當作寫工具的腳本語言用了, 完全對它的細節沒興趣

問題解決者不是通過學習解決問題而成為一個解決問題的人，問題解決者是通過不斷解決問題才成為一個能解決問題的人。（不知道是哪位大咖說的了）