以在Python社區總有關於Python框架孰優孰劣的話題。下面就給大家介紹壹下python的幾大框架：
Django
Django 應該是最出名的py框架，Google App Engine甚至Erlang都有框架受它影響。
Django是走大而全的方向，它最出名的是其全自動化的管理後臺：只需要使用起ORM，做簡單的對象定義，它就能自動生成數據庫結構、以及全功能的管理後臺。
Django提供的方便，也意味著Django內置的ORM跟框架內的其他模塊耦合程度高。
應用程序必須使用Django內置的ORM，否則就不能享受到框架內提供的種種基於其ORM的便利；理論上可以切換掉其ORM模塊，但這就相當於要把裝修完畢的房子拆除重新裝修，倒不如壹開始就去毛胚房做
全新的裝修。
Django的賣點是超高的開發效率，其性能擴展有限；采用Django的項目，在流量達到壹定規模後，都需要對其進行重構，才能滿足性能的要求。
而Django的缺點主要源自Django堅持自己造所有的輪子，整個系統相對封閉，Django最為人詬病的地方有：
· 系統緊耦合，如果妳覺得Django內置的某項功能不是很好，想用喜歡的第三方庫來代替是很難的，比如下面將要說的ORM、Template。要在Django裏用SQLAlchemy或Mako幾乎是不可能，即使打了壹
些補丁用上了也會讓妳覺得非常非常別扭。
· Django自帶的ORM遠不如SQLAlchemy強大，除了在Django這壹畝三分地，SQLAlchemy是Python世界裏事實上的ORM標準，其它框架都支持SQLAlchemy了，唯獨Django仍然堅持自己的那壹套。Django的
開發人員對SQLAlchemy的支持也是有 過討論和嘗試的，不過最終還是放棄了，估計是代價太高且跟Django其它的模塊很難合到壹塊。
· Template功能比較弱，不能插入Python代碼，要寫復雜壹點的邏輯需要另外用Python實現Tag或Filter。Django的模板系統設計十分有意思，也應該其框架內影響最大、爭議最大的部分。
Django模板的設計哲學是徹底的將代碼、樣式分離；asp.net提倡將代碼/模板分離，但技術上還是可以混合；而Django則是從根本上杜絕在模板中進行編碼、處理數據的可能。
比方說，asp.net模板中可以寫：
int i;
for(i==0;i
....
}
%>
Django是徹底不支持嵌入類似上面的代碼，僅能使用其模板內置的函數；這實際上，是為其模板構造了壹種“新語言”；由於此“新語言”十分簡單，所以也能夠將其模板移植到不同平臺。
大多數情況下，Django的模板功能是足夠的，但對於特殊（有時“特殊”也不是十分特殊）的情況，還是需要在模板中嵌入代碼，那麽就需要根據其模板系統的規則做模板擴展。有時候，模板中直接寫
壹行代碼能夠解決的問題，用模板擴展實現後，會變成十幾行代碼。
是否容忍在模板中編程，正是Django模板爭議最大之處。
Pylons & TurboGears & repoze.bfg
除了Django另壹個大頭就是Pylons了，因為TurboGears2.x是基於Pylons來做的，而repoze.bfg也已經並入Pylons project裏這個大的項目裏，後面不再單獨討論TurboGears和repoze.bfg了。
Pylons和Django的設計理念完全不同，Pylons本身只有兩千行左右的Python代碼，不過它還附帶有壹些幾乎就是Pylons禦用 的第三方模塊。Pylons只提供壹個架子和可選方案，妳可以根據自己的喜好自
由的選擇Template、ORM、form、auth等組件，系統高度可 定制。我們常說Python是壹個膠水語言(glue language)，那麽我們完全可以說Pylons就是壹個用膠水語言設計的膠水框架。
選擇Pylons多是選擇了它的自由，選擇了自由的同時也預示著妳選擇了噩夢：
· 學習噩夢，Pylons依賴於許多第三方庫，它們並不是Pylons造，妳學Pylons的同時還得學這些庫怎麽使用，關鍵有些時候妳都不知道妳 要學什麽。Pylons的學習曲線相對比Django要高的多，而之
前Pylons的官方文檔也壹直是人批評的對象，好在後來出了The Definitive Guide to Pylons這本書，這壹局面有所改觀。因為這個原因，Pylons壹度被譽為只適合高手使用的Python框架。
· 調試噩夢，因為牽涉到的模塊多，壹旦有錯誤發生就比較難定位問題處在哪裏。可能是妳寫的程序的錯、也可能是Pylons出錯了、再或是SQLAlchemy出錯了、搞不好是formencode有bug，反正很淩
亂了。這個只有用的很熟了才能解決這個問題。
· 升級噩夢，安裝Pylons大大小小***要安裝近20個Python模塊，各有各自的版本號，要升級Pylons的版本，哪個模塊出了不兼容的問題都有可能，升級基本上很難很難。至今reddit的Pylons還停留在
古董的0.9.6上，SQLAlchemy也還是0.5.3的版本，應該跟這條有關系。
Pylons和repoze.bfg的融合可能會催生下壹個能挑戰Django地位的框架。
Tornado & web.py
Tornado( 相比，Tornado有點類似僅實現了AsyncHttpHandler；除此之外，全部需要自己去實現。
好吧，其實它有模板，有國際化支持，甚至還有內置的OAuth/OpenID模塊，方便做第三方登錄，它其實也直接實現了Http服務器。
但它沒有ORM（僅有壹個mysql的超簡單封裝），甚至沒有Session支持，更不要說Django那樣自動化的後臺。
假設是壹個大型網站，在高性能的要求下，框架的各個部分往往都需要定制，可以復用的模塊非常少；壹個以Django開發的網站，各部分經過不斷的定制，Django框架剩下的，很有可能也就是tornado壹
開始所能提供的這部分。
殊途同歸。
HTTP服務器
Tornado為了高效實現Comet/後端異步調用HTTP接口，是直接內嵌了HTTP服務器。
前端無需加apache / lighttpd / nginx等也可以供瀏覽器訪問；但它並沒有完整實現HTTP 1.1的協議，所以官方文檔是推薦用戶在生產環境下在前端使用nginx，後端反向代理到多個Tornado實例。
Tornado本身是單線程的異步網絡程序，它默認啟動時，會根據CPU數量運行多個實例；充分利用CPU多核的優勢。
單線程異步
網站基本都會有數據庫操作，而Tornado是單線程的，這意味著如果數據庫查詢返回過慢，整個服務器響應會被堵塞。
數據庫查詢，實質上也是遠程的網絡調用；理想情況下，是將這些操作也封裝成為異步的；但Tornado對此並沒有提供任何支持。
壹個系統，要滿足高流量；是必須解決數據庫查詢速度問題的！
數據庫若存在查詢性能問題，整個系統無論如何優化，數據庫都會是瓶頸，拖慢整個系統！
異步並**不能**從本質上提到系統的性能；它僅僅是避免多余的網絡響應等待，以及切換線程的CPU耗費。
如果數據庫查詢響應太慢，需要解決的是數據庫的性能問題；而不是調用數據庫的前端Web應用。
對於實時返回的數據查詢，理想情況下需要確保所有數據都在內存中，數據庫硬盤IO應該為0；這樣的查詢才能足夠快；而如果數據庫查詢足夠快，那麽前端web應用也就無將數據查詢封裝為異步的必要
就算是使用協程，異步程序對於同步程序始終還是會提高復雜性；需要衡量的是處理這些額外復雜性是否值得。
如果後端有查詢實在是太慢，無法繞過，Tornaod的建議是將這些查詢在後端封裝獨立封裝成為HTTP接口，然後使用Tornado內置的異步HTTP客戶端進行調用。