今日最新排名已經殺入互動網銷售前十，特截圖留念，呵呵。
海貓msn上問我：能否幫著寫一篇《python原始碼剖析》的書評？他給我發這條資訊時，我正在聚精會神地敲一段超無聊的**，我看到這話嚇了一跳，腦子一激靈，手一顫抖，乙個偉大的死迴圈就此誕生。
我知道，這都是上次寫書評被人罵了之後留下的後遺症。教訓深刻呀，它讓我再次清醒地認識到，胡說八道是沒好下場的，作孽總會遭報應，只不過有現世現報的，有來世再報的，也有子子孫孫無窮報的，總之不是不報而是時候未到的。
所以這次我學乖了，在決定寫下以下的文字之前，我找海貓要了近一半的書稿內容，打算好好啃上十天半個月之後再碼個三五萬字的、足以讓魯迅先生汗顏的 書評出來，滅滅那幫鄙視我的it人的威風，並以此向他們證明一點，即老韓我在技術上菜是菜了一點，寫出來的文字也是俗了一點，罵人罵得是沒品位了一點，但 百無一是之中總有一樣是可取的，那就是：起碼我挑錯別字還是眼光毒辣的。
但事實證明我錯了，拿到書稿之後，翻完第四篇我就開始後悔，不僅後悔，甚至悔得連自殺的念頭都有。因為......理由嘛，就像現代社會女人口中的"愛"字一樣，很難說出口。待我梳弄完百結千愁的郭敬明式的憂傷，淺吟低唱著向你道來－－因為實在看不懂。
這是個歷史問題，其淵源可以追溯到long long ago的好幾年前，那時年少，風華正好，年輕的我有著年輕的心以及兩彎水汪汪的大眼睛，那時我在自學一門語言叫做c語言，用的教材是譚浩強老師的《c語言 程式設計》，數月後，自以為學有所得，甚是高興，高興之餘便開始誇下海口說我要搞程式設計，抱著這種想法，擠進了it圈。然而擠進門去之後卻沒高興太久，因為 慢慢的我發現，一般情況下的大部分時間裡，不是我在搞程式，而是程式在搞我。究其原因，是因為譚老師顯然是乙個理論家而非實踐家，在看他那偉大的《c語言 程式設計》的時候，他書中的大部分例子對我而言只是起到了酒精的作用：看時感覺很high很懂，而事實上轉天即忘。你知道，當一門偉大的語言墮落到只用於 解答純粹的數學問題而對解決實際問題百無一用的時候，學習者也容易墮入到自以為是的怪圈，即：自以為什麼都懂了，而事實上什麼都沒懂。不幸的是，在it圈 也如同在娛樂圈一樣，凡事也是要講潛規則的：做為乙個底層程式設計師，不是你能說會道資本家就會給你工資，做不出東西來
只有一條路可選那就是捲鋪蓋走人－－長 得帥被老闆娘看上的除外。
於是乎，滿以為找到**寶藏的我時運不齊、命途多舛，剛剛擠進門就被趕了出來。被趕出來之後我就再也沒有碰c這個東西。並轉行做起了設計和責編（混飯吃），再後來的故事就有點俗套了：因生計故，最後被逼良為那什麼成了一名php程式設計師並一路混到了今天。
當然，這段話和我要寫的書評完全沒有關係，按**的邏輯來說可以算是個楔子，即交代完主人公的前世今生，下面才是正文。
從上面的介紹您應該可以看到，我其實是個菜鳥。那麼，聰明的您、資深的您也許就要問了，這博文怎麼回事？找乙個這麼沒文化的菜鳥來寫書評，海貓同學腦子進水了吧？－－說得有道理，我估計也是，海貓嘛，在海上泡這麼久的貓，腦子不進水那是神，或者機器貓。
而事實是，高手是不寫書評的，高手都寫序去了，比如為這本書寫序的三位專家，那可是國內python界如雷貫耳的名字（我還就用誇張的詞，不怕你說我拍馬屁，何況，他們本來不是馬，你們鄙視不到我。）：
一、李迎輝（limodou，史稱木頭）：python-cn社群資深會員，貌似創始人之一？ulipad的作者。
三、馮大輝：著名dba，《learning python》（python語言入門）第一版的譯者之一，國內python先行者之一，dbanotes.net站長。
大家可以看到，大師們是不屑於寫書評的。但這活總有人幹呀對吧，所以，這就有我這等小角色的用武之地了。因為書評者，讀者眼中事也。
言歸正轉，首先說，這是一本好書－－無論你認同與否。或許你要說：扯吧你就，你幫別人寫書評，你當然不會說這是一本不好的書呀。隨便你怎麼理解，但我要說，這真的是一本好書，理由是：它除了是一本好書還是一本好書。（有這麼胡攪蠻纏的嗎？）
我有我的理由：
一、真正用python或者php做過**的都知道，指令碼語言最大的不足就是效率問題，同樣的乙個處理，用c寫的模組來處理，可能會比用指令碼語言寫 出來的快上10倍甚至更多，而這也正是php perl存在的理由以及諸多c寫的python模組存在的理由。舉乙個最直接的例子，在我用python來解析json的時候，經測試，cjson的處理 速度是py-json處理速度的9倍。而在我使用python-memcach模組的時候，也同樣有這樣的問題，c寫的模組，其匹配key的效率基本上是 py-memcache的4－5倍，尤其是對較長的字元key的匹配。這就說明，如果要寫出高效率的指令碼程式來，那麼用c來寫模組是必由之路，所謂演算法優 化之類的討論完全是屬於扯談，程式設計師中沒多少是很牛的數學家，如果你不能曲徑通幽，那我勸你還是老老實實地把握好語言的優勢，也可算是蹊徑之一。而 《python源**分析》正好為你提供了研究python核心**的知識，讓你成為python高效率程式開發員成為可能。
二、研究一門指令碼語言，深入的去研究其執行機制是很重要的，因為這可以為你以後寫出更高效率的**打下基礎，毫無疑問，乙個懂得指令碼程式執行機制的 開發人員，寫的程式無論是執行效率還是程式規範，都會比乙個只會字串操作的開發人員寫出來的強的。這就如，乙個懂得重力加速度以及人體脆弱部位的人與一 個啥都不懂的人，在跳樓自殺的效率上總是前者高於後者一樣（這什麼破比喻呀）。
三、縱觀全書，作者對python的物件機制、資料型別機制、編譯機制、記憶體管理機制，分析得還是比較透徹的，這在一定程度上有助於從c陣營轉過來的python新手更快的理解python。
四、這本書的作者陳儒老師文學功底很深，像個文人，縱觀全書，諸多詞彙信手拈來，行雲流水。拋開其中一些晦澀的術語不談，光文字就很精彩。比如下面 這很有意思的一段："列位看官，花開兩朵，各表一枝。我們先把這個問題放一放，看一看在python開始執行時，第乙個pylistobject物件被創 建時的情形。嗯，這有點像上帝創世紀，挺有趣的。"－－是不是有點古龍或者金庸的味道？
當然，不能總是誇獎，也有不足，不足之處在於有些地方作者太過於注重語言表達而不是平鋪直敘，我覺得這可能是作者忽略了技術書的使命的結果，或者也 許是作者對自己文字水平太過自信的結果，無論如何，我們不得不承認的是，作者的優點也恰恰是其缺點。儘管書中太量的例項在一定程度上彌補了這種不足，但瑕 不掩疵，終為詬病。
而需要說明的是，這書說實話並不適合python初學者，尤其是沒有c或者c＋＋基礎的初學者。
以上為個人看了幾篇樣章之後的觀感，不足成其為書評。只算是一家之言吧。如前面所言，本人技術水平不怎麼樣，不敢做更深層次的技術上的評判，但願沒有誤導您。倘若誤導成為了事實，歡迎你罵我，但請別帶上我爸媽以及我的親人－－因為他們比我更不懂技術，這不是他們的錯。
黃冬先生推薦序
馮大輝先生推薦序
limodou先生推薦序
作者陳儒先生部落格
Lua與C C 的互動
lua 從 取得 luatinker 可以從 取得 tolua 可以從 取得 關於lua與c c 的互動 c c 呼叫lua的函式還是比較簡單的，可以參考lua tinker的實現。lua呼叫c c 的函式如果用最原始的方式有很大限制，只能呼叫型別為 typedef int lua cfunctio...
lua與C C 的互動
基於vs的lua原始碼，位址為 lua作為小巧精悍的指令碼語言，易於嵌入c c 中 廣泛應用於遊戲ai 實際上在任何經常變化的邏輯上都可以使用lua實現，配合c c 實現的底層介面服務，能夠大大降低系統的維護成本。下面對lua和c c 的互動呼叫做乙個例項分析 lua提供了api用於在c c 中構造...
Lua與C C 互動函式問題
初學lua，遇到註冊c c 互動函式問題 在lua與c c 互動時，c c 的註冊lua函式若是乙個有返回型別 壓棧 而不是獲取型別的時候應該返回1而不是返回0，否則會出現在lua中值為nil 空 不太明白為什麼事這樣，如果有知道的大神，麻煩講解下 如 應該是 1 2 3 4 5 6 intcrea...