Django 與 Tornado 各自的優缺點
Django
優點：
大和全（重量級框架）
自帶orm，template，view
需要的功能也可以去找第三方的app
注重高效開發
全自動化的管理后台（只需要使用起ORM，做簡單的定義，就能自動生成數據庫結構，全功能的管理后台）
session功能
缺點：
template不怎么好用（來自自身的缺點）
數據庫用nosql不方便（來自自身的缺點）
如果功能不多，容易臃腫
Tornado
優點：
少而精（輕量級框架）
注重性能優越，速度快
解決高並發（請求處理是基於回調的非阻塞調用）
異步非阻塞
websockets 長連接
內嵌了HTTP服務器
單線程的異步網絡程序，默認啟動時根據CPU數量運行多個實例；利用CPU多核的優勢
自定義模塊
缺點：
模板和數據庫部分有很多第三方的模塊可供選擇，這樣不利於封裝為一個功能模塊
總結：
要性能， Tornado 首選；要開發速度，Django 和 Flask 都行，區別是 Flask 把許多功能交給第三方庫去完成了，因此 Flask 更為靈活。
綜上所述：
Django適合初學者或者小團隊的快速開發，適合做管理類、博客類網站、或者功能十分復雜需求十分多的網站
Tornado適合高度定制，適合訪問量大，異步情況多的網站
Django 概述
Django 應該是最出名的python框架，Google App Engine甚至Erlang都有框架受它影響。
Django是走大而全的方向，它最出名的是其全自動化的管理后台：只需要使用起ORM，做簡單的對象定義，它就能自動生成數據庫結構、以及全功能的管理后台。
Django提供的方便，也意味着Django內置的ORM跟框架內的其他模塊耦合程度高。
應用程序必須使用Django內置的ORM，否則就不能享受到框架內提供的種種基於其ORM的便利；理論上可以切換掉其ORM模塊，但這就相當於要把裝修完畢的房子拆除重新裝修，倒不如一開始就去毛胚房做全新的裝修。
Django的賣點是超高的開發效率，其性能擴展有限；采用Django的項目，在流量達到一定規模后，都需要對其進行重構，才能滿足性能的要求。
Ruby的Rails也有類似的問題；以Twitter為例，推特到了今日的規模，不要說Rails，甚至是連Ruby都需要拋棄重來。
就我的感覺Django適用的是中小型的網站，或者是作為大型網站快速實現產品雛形的工具。
Tornado 概述
Tornado是Facebook開源出來的框架，其哲學跟Django近乎兩個極端。Tornado是異步框架Tornado基本上只算有MVC中C這一層
Tornado走的是少而精的方向，它也有提供模板功能；雖然不鼓勵，但作者是可以允許在模板進行少量編碼的。
如果跟asp.net相比，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對此並“沒有”提供任何支持。
這是Tornado的“設計”，而不是缺陷。
一個系統，要滿足高流量；是必須解決數據庫查詢速度問題的！
數據庫若存在查詢性能問題，整個系統無論如何優化，數據庫都會是瓶頸，拖慢整個系統！
異步並**不能**從本質上提到系統的性能；它僅僅是避免多余的網絡響應等待，以及切換線程的CPU耗費。
如果數據庫查詢響應太慢，需要解決的是數據庫的性能問題；而不是調用數據庫的前端Web應用。
對於實時返回的數據查詢，理想情況下需要確保所有數據都在內存中，數據庫硬盤IO應該為0；這樣的查詢才能足夠快；而如果數據庫查詢足夠快，那么前端web應用也就無將數據查詢封裝為異步的必要。
就算是使用協程，異步程序對於同步程序始終還是會提高復雜性；需要衡量的是處理這些額外復雜性是否值得。
如果后端有查詢實在是太慢，無法繞過，Tornaod的建議是將這些查詢在后端封裝獨立封裝成為HTTP接口，然后使用Tornado內置的異步HTTP客戶端進行調用。
Django是基於python的web框架，直接使用了WSGI，
Django請求流程
1.用戶通過瀏覽器發送請求
2.請求到達request中間件，中間件對request請求做預處理或者直接返回response
3.若未返回response，會到達urlconf路由，找到對應視圖函數
4.視圖函數做相應預處理或直接返回response
5.View中的方法可以選擇性的通過Models訪問底層的數據
6.取到相應數據后回到django模板系統，templates通過filter或tags把數據渲染到模板上
7.返回response到瀏覽器展示給客戶
上述流程中最主要的幾個部分分別是：Middleware(中間件，包括request, view, exception, response)，URLConf(url映射關系)，Template(模板系統
注重高效開發
全自動化的管理后台（只需要使用起ORM，做簡單的定義，就能自動生成數據庫結構，全功能的管理后台）
session功能
django的優點在於 大和全 ，orm，template，view 都自帶了。需要的功能也可以去找第三方的app。 缺點嘛也就是自身的一些缺點，template不怎么好用，數據庫用nosql不方便等。
注重性能優越，速度快
解決高並發
異步非阻塞
websockets 長連接
內嵌了HTTP服務器
單線程的異步網絡程序，默認啟動時根據CPU數量運行多個實例；利用CPU多核的優勢。
tornado的模板感覺更簡單點。而且請求處理是基於回調的非阻塞調用，這樣能提高並發量。 模板和數據庫部分有很多第三方的模塊可供選擇，這樣不利於封裝為一個功能模塊。缺點倒也不至於，因為本來就打算成為一個輕量級的框架吧
1.要性能， Tornado 首選；要開發速度，Django 和 Flask 都行，區別是 Flask 把許多功能交給第三方庫去完成了，因此 Flask 更為靈活。
3.Django適合初學者或者小團隊，Tornado適合高度定制。
1，tornado：是python編寫的web服務器兼容web應用的框架。
tornado的優勢
（1），輕量級的web框架
（2），他提供了一種帶有異步功能並允許他擴展到大量開放連接的簡單的web框架。
（3），出色的坑負載能力
（4），優異的處理性能，不依賴多線程/多進程。
（5），wsgi全棧替代產品，推薦同時使用其web框架和http服務器。
2，Django框架
Django：是重量級的web框架，功能大而且全，可以高效開發。
原因：
（1），內置的管理后台
（2），內置封裝完善的ORM操作
（3），session功能，
（4），后台管理
（5）HTTP服務器
（6），異步編程
-
從數據庫來說
django有自己的ORM,而tornado的torndb不是很強大,所以一般都使用sqlalchemy
-
從視圖上來說
-
django可以用form做一些驗證
-
render中django沒有tornado可以傳的參數類型多
-
-
性能上來說
tornado由於是單線程異步回調的模式,所以比django的並發要高
django是多線程但是沒有做異步,所以要比tornado的並發低
-
從提供的插件上來說
django提供了ORM,django.core.mail,django crontab,等等
-
Python幾種主流框架
從GitHub中整理出的15個最受歡迎的Python開源框架。這些框架包括事件I/O，OLAP，Web開發，高性能網絡通信，測試，爬蟲等。
Django: Python Web應用開發框架
Django 應該是最出名的Python框架，GAE甚至Erlang都有框架受它影響。Django是走大而全的方向，它最出名的是其全自動化的管理后台：只需要使用起ORM，做簡單的對象定義，它就能自動生成數據庫結構、以及全功能的管理后台。
Diesel：基於Greenlet的事件I/O框架
Diesel提供一個整潔的API來編寫網絡客戶端和服務器。支持TCP和UDP。
Flask：一個用Python編寫的輕量級Web應用框架
Flask是一個使用Python編寫的輕量級Web應用框架。基於Werkzeug WSGI工具箱和Jinja2
模板引擎。Flask也被稱為“microframework”，因為它使用簡單的核心，用extension增加其他功能。Flask沒有默認使用的數
據庫、窗體驗證工具。
Cubes：輕量級Python OLAP框架
Cubes是一個輕量級Python框架，包含OLAP、多維數據分析和瀏覽聚合數據（aggregated data）等工具。
Kartograph.py：創造矢量地圖的輕量級Python框架
Kartograph是一個Python庫，用來為ESRI生成SVG地圖。Kartograph.py目前仍處於beta階段，你可以在virtualenv環境下來測試。
Pulsar：Python的事件驅動並發框架
Pulsar是一個事件驅動的並發框架，有了pulsar，你可以寫出在不同進程或線程中運行一個或多個活動的異步服務器。
Web2py：全棧式Web框架
Web2py是一個為Python語言提供的全功能Web應用框架，旨在敏捷快速的開發Web應用，具有快速、安全以及可移植的數據庫驅動的應用，兼容Google App Engine。
Falcon：構建雲API和網絡應用后端的高性能Python框架
Falcon是一個構建雲API的高性能Python框架，它鼓勵使用REST架構風格，盡可能以最少的力氣做最多的事情。
Dpark：Python版的Spark
DPark是Spark的Python克隆，是一個Python實現的分布式計算框架，可以非常方便地實現大規模數據處理和迭代計算。DPark由豆瓣實現，目前豆瓣內部的絕大多數數據分析都使用DPark完成，正日趨完善。
Buildbot：基於Python的持續集成測試框架
Buildbot是一個開源框架，可以自動化軟件構建、測試和發布等過程。每當代碼有改變，服務器要求不同平台上的客戶端立即進行代碼構建和測試，收集並報告不同平台的構建和測試結果。
Zerorpc：基於ZeroMQ的高性能分布式RPC框架
Zerorpc是一個基於ZeroMQ和MessagePack開發的遠程過程調用協議（RPC）實現。和 Zerorpc 一起使用的 Service API 被稱為 zeroservice。Zerorpc 可以通過編程或命令行方式調用。
Bottle: 微型Python Web框架
Bottle是一個簡單高效的遵循WSGI的微型python Web框架。說微型，是因為它只有一個文件，除Python標准庫外，它不依賴於任何第三方模塊。
Tornado：異步非阻塞IO的Python Web框架
Tornado的全稱是Torado Web Server，從名字上看就可知道它可以用作Web服務器，但同時它也是一個Python Web的開發框架。最初是在FriendFeed公司的網站上使用，FaceBook收購了之后便開源了出來。
webpy: 輕量級的Python Web框架
webpy的設計理念力求精簡（Keep it simple and powerful），源碼很簡短，只提供一個框架所必須的東西，不依賴大量的第三方模塊，它沒有URL路由、沒有模板也沒有數據庫的訪問。
Scrapy：Python的爬蟲框架
Scrapy是一個使用Python編寫的，輕量級的，簡單輕巧，並且使用起來非常的方便。
2018年Python web五大主流框架
我們都知道風靡一時的Python語言作為人工智能戰場上主要使用的槍外，還被廣泛應用在Web開發、游戲開發、人工智能、雲計算開發、大數據開發、數據分析、科學運算、爬蟲、自動化運維、自動化測試等領域，其實Python在各領域的應用最方便的就是使用框架，可以讓程序員以更少的代碼實現自定義功能，還可以將更多的精力集中在業務邏輯上，更加的輕松便利!那么2018年Python web五大主流框架，你知道嗎?
序言：
現在很多學習Python的人員更多的是趨向於爬蟲、人工智能、數據分析等，Python web開發確實這些方向工作崗位最多的一個!曾經有一位老前輩和說到“Python web開發堪稱全能”。
他說：
如果你會Python web開發，那么
你在制造行業，就是做ERP系統開發;
你在電商行業，就是做電商平台;
你在游戲行業，就是做游戲后台開發;
你在金融行業，就是做量化交易;
你在.......行業，就是做.................................
既然Python web這么厲害，那么我們了解2018Python主流的五大框架也就顯得很有必要了：
1.Django
Django是一個開源的Web應用框架，由Python寫成，支持許多數據庫引擎，可以讓Web開發變得迅速和可擴展，並會不斷的版本更新以匹配Python最新版本，如果是新手程序員，可以從這個框架入手。
2.Flask
Flask是一個輕量級的Web應用框架, 使用Python編寫。基於 WerkzeugWSGI工具箱和 Jinja2模板引擎。使用 BSD 授權。
Flask也被稱為 “microframework” ，因為它使用簡單的核心，用 extension 增加其他功能。Flask沒有默認使用的數據庫、窗體驗證工具。然而，Flask保留了擴增的彈性，可以用Flask-extension加入這些功 能：ORM、窗體驗證工具、文件上傳、各種開放式身份驗證技術。
3.Web2py
Web2py是一個用Python語言編寫的免費的開源Web框架，旨在敏捷快速的開發Web應用，具有快速、可擴展、安全以及可移植的數據庫驅動的應用，遵循LGPLv3開源協議。
Web2py提供一站式的解決方案，整個開發過程都可以在瀏覽器上進行，提供了Web版的在線開發，HTML模版編寫，靜態文件的上傳，數據庫的編寫的功能。其它的還有日志功能，以及一個自動化的admin接口。
4.Tornado
Tornado即是一個Web server(對此本文不作詳述)，同時又是一個類web.py的micro-framework，作為框架Tornado的思想主要來源於Web.py，大家在Web.py的網站首頁也可以看到Tornado的大佬Bret Taylor的這么一段話(他這里說的FriendFeed用的框架跟Tornado可以看作是一個東西)：
“[web.py inspired the] Web framework we use at FriendFeed [and] the webapp framework that ships with App Engine…”
因為有這層關系，后面不再單獨討論Tornado。
5.CherryPy
CherryPy是一種用於Python的、簡單而非常有用的Web框架，其主要作用是以盡可能少的操作將Web服務器與Python代碼連接，其功能包括內置的分析功能、靈活的插件系統以及一次運行多個HTTP服務器的功能，可與運行在最新版本的Python、Jython、Android上。
最后關於框架選擇的誤區
在框架的選擇問題上，許多人很容易就陷入了下面兩個誤區中而不自知：
-
哪個框架最好——世上沒有最好的框架，只有最適合你自己、最適合你的團隊的框架。編程語言選擇也是一個道理，你的團隊Python最熟就用Python好了，如果最熟悉的是Ruby那就用Ruby好了，編程語言、框架都只是工具，能多、快、好、省的干完活就是好東西。
-
過分關注性能——其實大部分人是沒必要太關心框架的性能的，因為你開發的網站根本就是個小站，能上1萬的IP的網站已經不多了，上10萬的更是很少很少。在沒有一定的訪問量前談性能其實是沒有多大意義的，因為你的CPU和內存一直就閑着呢。
13個Python web框架比較
Python程序員有很多很好的選擇來創建Web應用程序和API；Django，Weppy，Bottle和Flask引領潮流。
如果正在開發一個Web應用程序並且已經選擇使用Python作為構建它的語言，那么這是一個明智的選擇。Python的開發成熟度，強大的庫以及廣泛的實際應用使其成為Web開發的必需。
現在是困難的部分：從眾多可用的Python web框架中選擇一個。它們不僅數量在不斷增長，而且很難找到最適合你的。如果你正在構建一個快速而又簡單的REST API，那么你將不需要任何完整的面向用戶的應用程序所需的管道和連接，該應用程序具有用戶登錄、表單驗證和上傳處理就可以了。
在本文中，我們將研究13種最廣泛部署的Python web框架。我們將關注每種web應用程序最適合構建哪種類型的web應用程序，並研究它們如何在以下六個方面相互競爭:
安裝：設置不需要正式的框架項目(它可以簡單地作為包含的模塊放到現有的項目中)、啟動所需的模板文件最少、或者帶有某種預先配置的設置，這是多么容易或簡單。
文檔：幾乎每一個像樣的Python項目都有文檔，可以遍歷設置、演示基本用例並提供關於API的詳細信息。在這里，我們給這樣的框架更高的分數：這些框架展示了如何在教程中創建整個應用程序，包括常見的配方或設計模式，以及超出職責范圍（例如提供有關如何運行的詳細信息） Python變體（如PyPy或IronPython）下的框架。
管理：這是相對得分，表示配置和維護框架需要做多少工作。默認情況下，工作量最小的框架得分更高。
原生能力：包含多少組件？得分較高的是那些為國際化，HTML模板和數據訪問層提供原生支持的框架。還有一些框架使用Python最近引入的異步I/O操作的原生支持。
安全性：提供原生安全措施（如跨站點請求偽造（CSRF）保護和使用加密cookie的會話管理）的框架獲得更高的分數。
可伸縮性：大多數Python框架可以利用像Gevent或Gunicorn這樣的項目來大規模運行。在這里，我們看一下提升可伸縮性的框架原生特性，如輸出和頁面片段緩存。
如果你對性能基准感到好奇，請查看TechEmpower正在進行的一系列試驗，這些試驗比較了各種任務中的多個Web框架，並將代碼和方法發布到GitHub並進行不斷的重新評估。並非所有討論中的框架都在那里進行了分析，但是可以很好地了解哪種框架在哪種負載下表現最佳。
我們將分析13個框架。其中五個：CubicWeb，Django，Web2py，Weppy和Zope2，采用“控件”方法，包含你可以想象的Web應用程序所需的大多數功能。其余八個框架： Bottle，CherryPy，Falcon，Flask，Pyramid，Tornado，Web.py和Wheezy.web，提供更簡約的外觀，交易批量和完整性，簡單易用。
讓我們從重量級開始吧。
重量級的Python Web框架
CubicWeb
CubicWeb被稱為“一個支持重用和面向對象設計的語義Web應用程序框架。”這是一個有趣的系統，強調使用抽象和可重用的代碼塊稱為“多維數據集”，但對於某些開發人員來說可能過於抽象或特殊。
多維數據集是具有模式（數據模型），實體（編程邏輯）和視圖的軟件組件。通過組合多個立方體，每個立方體執行自己的任務，可以通過重用自己的代碼和其他代碼來編寫軟件應用程序。
CubicWeb的核心是提供每個Web應用程序使用的基本搭建材料：用於數據連接和存儲的“存儲庫”；用於基本HTTP請求/響應和CRUD操作的“Web引擎”；以及用於建模數據的模式。所有這些都在Python類定義中描述。要設置和管理CubicWeb的實例，可以使用類似於Django的命令行工具。
CubicWeb似乎沒有使用Python 3的原生異步功能。包含異步的一種迂回方式是使用cubicweb.pyramid模塊將Pyramid框架用作Web服務器，並使用異步構造在Pyramid上繪制。但是現在看起來更加直截了當。
要在CubicWeb應用程序中獲取或操作持久數據，可以使用關系查詢語言（RQL），它采用模糊的SQL語法，但在W3C的SparQL之后進行模式化。CubicWeb的理由再次是抽象：RQL提供了一種高度分離的路徑來相互關聯各種數據源。但是，隨着它的實現，通過手動構建查詢作為字符串，它可能會讓習慣於ORM的開發人員感到過時。
使用CubicWeb還有其他障礙。首先，設置可能很麻煩。因為CubicWeb有很多依賴項，所以最好使用pip install來獲取所有依賴項。可能還必須在本地環境中執行一定數量的手動調整。這與運行pip install或將框架代碼放入另一個項目的子文件夾的其他框架形成鮮明對比，這就是所需要的。
另一個潛在的問題是缺少本機模板引擎；生成HTML留給開發人員。可以通過使用像Jinja2這樣的第三方模板系統或選擇為Web UI提供工具的多維數據集來克服這個問題，例如Boostrap HTML框架的工具。
CubicWeb的一個長期問題，缺乏Python 3支持，目前已經解決。截至2016年6月的版本3.23，CubicWeb支持Python 3，但Twisted等模塊本身並未完全移植。
與Web2py一樣，CubicWeb將其冗長的文檔稱為“書籍”。它需要時間來解釋CubicWeb的不尋常方法，演示如何構建一些基本應用程序，包括API引用，並且通常不會特定的方式。
Django
自Django首次出現以來已經有十年，它已經成為Python最廣泛部署的用於創建Web應用程序的框架之一。 Django配備了你可能需要的大部分組件，因此它傾向於構建大型應用程序而不是小型應用程序。
經過多年在版本1.x后，Django最近在小數點的左邊創建了一個版本。 Django 2.0中最大的變化是框架現在只適用於Python 3.4及更高版本。理想情況下，你應該使用Python 3.x，所以使用Django的1.x分支的唯一原因是你遇到了舊版本的Python。
Django吸引力的一個關鍵部分是部署速度。因為它包含了開發普通Web應用程序所需的許多部分，所以可以快速行動。路由，URL解析，數據庫連接（包括ORM），表單驗證，攻擊保護和模板都是內置的。
將找到最常見的Web應用程序方案的構建塊。例如，用戶管理可在大多數網站上找到，因此Django將其作為標准元素提供。Django本身具有這些功能，而不必創建自己的系統來跟蹤用戶帳戶，會話，密碼，登錄/注銷，管理員權限等。它們可以按原樣使用或擴展，以包含最少量工作的新用例。
核心是BSD，一些組件是LGPLv3。可通過zope.formlib獲得；單獨安裝但作為項目的一部分支持。通過第三方擴展程序提供。
Django具有健全和安全的默認設置，有助於保護Web應用程序免受攻擊。將變量放在頁面模板中時，例如帶有HTML或JavaScript的字符串，除非明確將變量實例指定為安全，否則不會按字面意義呈現內容。這本身就減少了許多常見的跨站腳本問題。如果要執行表單驗證，可以使用從簡單的CSRF保護到返回詳細錯誤反饋的完整逐個字段驗證機制的所有內容。
如果沒有強大的文檔可以使用像Django那樣豐富和廣泛的功能。Django的文檔站點從多個角度深入研究框架的各個方面。使用Python 3或其他語言，正確的安全性，實現常見的Web應用程序組件（如會話或分頁），生成站點地圖，它們都被覆蓋。還詳細描述了應用程序模型，視圖和模板的每個層的API。
然而，強大的力量帶來了極大的復雜性。Django應用程序以其頭重腳輕而聞名，具有許多移動部件。即使只有幾條路線的簡單Django應用程序也需要相當多的配置才能運行。如果你的工作只是設置幾個簡單的REST端點，Django幾乎肯定是矯枉過正的。
Django也有它的怪癖。例如，頁面模板不能使用callables。示例：可以將{{user.name}}作為模板中的組件傳遞，但不能傳遞{{user.get_name（）}}。這是Django確保模板不會無意中做出令人討厭的事情的方法之一，但如果你沒有為它們做好准備，這些限制可能會很刺激。雖然有解決方法，但它們往往會對性能產生影響。
Django的核心是同步。但是，添加異步行為的一種方法是通過Django Channels項目。這個項目是官方的Django附加組件，它為Django添加了對連接和套接字的異步處理，同時保留了Django的編程習慣用法。
web2py
在Ruby世界中，Ruby on Rails是事實上的Web框架。DePaul大學計算機科學教授Massimo Di Pierro受到Rails的啟發，用Python創建一個易於設置和使用的Web框架。結果是Web2py。
Web2py最大的吸引力在於其內置的開發環境。當設置Web2py實例時，將獲得一個Web界面，實際上是一個在線Python應用程序編輯器，可以在其中配置應用程序的組件。這通常意味着創建模型，視圖和控制器，每個都通過Python模塊或HTML模板進行描述。一些示例應用程序隨附Web2py。可以將它們分開來查看它們的工作方式，或將它們用作啟動器模板來創建自己的應用程序。
開發人員通常只需下載源代碼並使用它來部署Web2py。但對於Windows或MacOS上技術含量較低的用戶，Web2py的創建者提供的版本基本上是獨立服務器。下載，解壓縮並運行其中一個版本，將擁有一個內置Web2py預配置副本的本地Web服務器。這是一個很好的方法來創建一個Web2py應用程序，然后可以部署其他地方。
Web2py的Web界面是使用Bootstrap 2.16.1構建的，因此它易於操作並且易於導航。瀏覽器內編輯器不能替代完整的IDE，但它配備了有用的輔助工具，如行編號和Python語法高亮（包括自動縮進）。還包括一個Python shell的快速Web界面，因此如果需要，可以從命令行與Web2py交互，這對專家來說是一個很好的讓步。
Web2py中使用的數據抽象系統與Django的ORM和受其啟發的其他ORM（例如Peewee）略有不同。這些系統使用Python類來定義模型，在Web2py中，使用構造函數（如define_table）來實例化模型。這些差異中的大部分可能只會對那些已經有過經驗並且開始使用另一個的人產生震動；他們對新人來說同樣復雜。將Web2py連接到數據提供者可能不會遇到任何麻煩，因為它幾乎涉及現有的每個主要數據庫。
一個真正有用的數據庫相關功能是生成模型圖的能力，更好地可視化模型之間的相互關系。但是，需要安裝pygraphviz庫才能啟用該功能。
Web2py通過對jQuery和AJAX的集成支持，提供許多其他專業級組件：國際化功能，多種緩存方法，訪問控制和授權，甚至前端效果（例如，表單中的日期選擇器）。雖然不允許使用中間件來替換核心Web2py功能，但也包括外部和內部中間件的掛鈎。
Web2py的一個重要限制是它僅與Python 2.x兼容。首先，這意味着Web2py無法使用Python 3的異步語法。如果你依賴於Python 3獨有的外部庫，那么你就不走運了。但是，正在開展使Web2py Python 3兼容的工作，並且在撰寫本文時它已接近完成。
毫無疑問，Web2py的文檔被稱為“書”。首先，它涵蓋了Web2py，Python以及用於這兩者的部署環境的大量材料。其次，它以高度可訪問的敘事風格書寫。第三，它深入討論了常見的應用程序構建方案。例如，有一整章使用jQuery（與Web2Py捆綁在一起）來構建AJAX應用程序。
Weppy
Weppy感覺就像Flask的簡約風格和Django的完整性之間的中間標記。雖然開發Weppy應用程序具有Flash的直接性，但Weppy具有Django中的許多功能，如數據層和身份驗證。因此，Weppy適用於從極其簡單到適度復雜的應用程序。
乍一看，Weppy代碼看起來很像Flask或Bottle代碼。啟動和運行基本的單路網站需要很少的指示。路徑可以通過函數裝飾器（簡單方法）或以編程方式描述，並且這樣做的語法與Flask/Bottle密切相關。除了語法的微小變化外，模板的工作方式大致相同。
Weppy與其他框架形成鮮明對比，包括它們僅作為插件或附加組件包含的一些功能。例如，Flask和Bottle都沒有內置的ORM或數據管理系統。Weppy包含一個ORM，雖然它是基於pyDAL項目而不是更受歡迎的SQLAlchemy。Weppy甚至支持模式遷移，Django支持模式遷移作為其ORM的一部分（同樣，Django的遷移系統也更加自動化）。雖然Weppy有一個擴展機制，但官方批准的附加組件列表很小，遠小於Flask的擴展目錄。
像Weppy這樣的輕量級框架通常用於構建RESTful API，而Weppy則為此配備了便利功能。在路由上放置一個@service修飾器，返回的數據將自動格式化為選擇的JSON或XML。
Weppy包含的其他功能更符合更大的框架，但它們是在沒有批量的情況下實現的。示例：數據驗證機制，表單處理，響應緩存和用戶驗證。在所有這些情況下，Weppy采取“恰到好處”的方法。提供的功能並不像在Django大小的框架中那樣完整，但開發人員不需要投入大量精力來使它們變得有用，並且它們可以在事后得到擴展。
Weppy中發現的另一個通常與更重量級框架相關的功能是國際化支持。模板中的字符串可以根據應用程序提供的區域設置文件進行翻譯，這些文件是簡單的Python字典。也可以通過解析瀏覽器請求（即Accept-Language HTTP標頭）或將翻譯綁定到特定路由來設置語言選擇。
Weppy的文檔與框架本身具有相同的風格。它干凈，可讀，並且被人類消費。除了通常的“hello world”應用程序示例之外，它還包含一個很好的演練教程，可以讓你創建一個微博系統作為初學者項目。
Weppy的長期計划包括支持異步和套接字作為低級一流實體。 Weppy的開發人員計划在2.0版本中引入這些功能，然后要求所有未來版本的Weppy使用Python 3.7或更高版本。
Zope2
Zope不適用於簡單的RESTful API（每Bottle或Flask），甚至不適用於具有交互性的基本網站（à la Django）。相反，它意味着是一個完整的企業級應用程序服務器堆棧，類似於Java產品。該文檔將該框架描述為“對組件開發人員，整合者和Web設計人員最有用。”一個主要的第三方產品Plone CMS使用Zope作為其基礎，並作為Zope持續開發的主要驅動力。
Zope通過從Web獲取請求，將請求的參數與內部對象數據庫（ZODB）匹配，並使用請求的GET或POST參數執行該對象來工作。無論從對象返回什么，都會返回給客戶端。 Zope使用此數據庫對象系統來簡化任務，例如分配粒度對象權限，為對象提供繼承層次結構，以及處理數據庫對象的事務和回滾。
由於Zope的尺寸和復雜性，安裝需要一些工作；這不是簡單地將源解壓縮到項目子文件夾中的問題。一些設置過程包括編譯C模塊，因此在Windows上安裝很棘手。自2010年以來，Zope的預打包Windows二進制文件尚未更新，並且圍繞它們的文檔狀態使得很難確定設置的最佳實踐。但是，實際框架的文檔非常好。 Zope2 Book是一本非常詳細的綱要。
當啟動Zope並連接到服務器時，將看到Web UI，可以在其中創建和編輯ZODB對象。對象采用三種基本角色之一：內容，邏輯和表示，並且可以包含文檔（基本上，任何具有MIME類型的文件），Python腳本和HTML模板。
模板可以是兩種類型之一：新的和更靈活的Zope頁面模板（ZPT）系統，或舊的和更基本的DTML標記系統。ZPT使用HTML標記中的屬性來指示數據的放置位置，從而可以更輕松地使用傳統的HTML工具設計模板。但是ZPT語法需要一些時間來習慣。
Zope聲稱其面向對象方法的優點之一是系統中的每個操作，無論它作用於何種對象，都由事務封裝。因此，如果刪除存儲在Zope數據庫中的文件或對一段代碼進行破壞性更改，則只需回滾執行它的操作。缺點是很難在這樣的代碼庫上使用像Git這樣的現代源代碼控制工具，這意味着你將數據放在Zope的自定義數據庫工具的支配下。請注意，可以將MySQL之類的外部數據庫連接到Zope應用程序，但這主要用於托管應用程序數據，而不是替換ZODB。
與這里討論的許多較小的，更靈活的框架相比，Zope的遺留和大小轉化為許多缺點。最大的缺點是Zope只能在Python 2.x下運行，所以不能利用Python 3庫或異步語法，盡管正在努力解決這個問題。 （Zope 4仍處於測試階段，包括Python 3支持以及更多支持。）
輕量級的Python Web框架
Bottle
Bottle可以被認為是一種迷你燒瓶，因為它比其他“微框架”更加緊湊和簡潔。由於其占地面積最小，Bottle非常適合包含在其他項目中或快速交付REST API等小型項目。
Bottle的整個代碼庫適合單個文件，並且絕對沒有外部依賴性。即便如此，Bottle還配備了足夠的功能來構建常見的Web應用程序，而無需依賴外部幫助。
Bottle中的路由系統將URL映射到函數，其語法與Flask幾乎完全相同。也不僅限於硬連線路徑；可以動態創建它們。可以通過Bottle框架中的對象訪問和操作請求和響應數據，cookie，查詢變量，來自POST操作的表單數據，HTTP標頭和文件上載。
每項功能都經過精心細致的實施。例如，使用文件上載，如果文件的命名約定與目標文件系統沖突（例如Windows上的名稱中的斜杠），則不必重命名該文件;瓶子可以幫到你。
Bottle包含自己的簡單HTML模板引擎。同樣，雖然很小，但它已經裝配好了必需品。默認情況下，模板中包含的變量使用安全HTML呈現;你必須指出哪些變量可以安全地從字面上重現。如果更換掉模板引擎並使用另一個模板引擎，例如Jinja2，那么Bottle可以幫助輕松完成。我其實喜歡與Bottle捆綁的簡單模板系統；它的語法不起眼，它允許混合代碼和模板文本而不會有不適當的困難。
Bottle甚至支持多個服務器后端。它配備了自己的內置miniserver以進行快速測試，但可以支持各種兼容WSGI的HTTP服務器，並在需要時可以回退到普通的舊CGI。
Bottle不需要像其他框架那樣多的文檔，但文檔絕不是吝嗇。所有關鍵的東西都適合單個（盡管很長）的網頁。除此之外，還可以找到每個API的完整文檔，如何在各種基礎架構上進行部署的示例，內置模板語言的解釋以及一系列常見配方。
與Flask一樣，可以手動或通過編寫補充瓶的插件擴展Bottle的功能。 Bottle插件列表遠不及Flask的大小，但有一些有用的部分，例如與各種數據庫層的集成和基本的用戶身份驗證。對於異步支持，Bottle可以使用異步運行的現有服務器適配器之一，例如aiohttp/uvloop。
Bottle極簡主義的一個后果是有些功能根本就不存在。不支持表單驗證，包括CSRF保護等功能。如果要構建支持高度用戶交互的Web應用程序，則需要自己添加它們。
CherryPy
CherryPy已經存在了超過10年，但並沒有失去最初區分它的極簡主義和優雅。
這個框架的前提是，除了只包含為web頁面提供服務所需的少量內容外，它應該盡可能地讓人感覺它不像“web框架”，而是像任何其他類型的Python應用程序一樣。根據文件顯示，Hulu和Netflix等網站在制作中使用了CherryPy，這可能是因為該框架提供了一個高度低調的基礎。
CherryPy可以將Web應用程序與核心邏輯區分開來。要將應用程序的功能映射到CherryPy提供的URL或路由，需要創建一個類，其中對象的名稱空間直接映射到您要提供的URL；例如，網站的根由名為“index”的函數提供。傳遞給這些函數的參數用於處理由GET或POST方法提供的變量。
CherryPy包含的位用作低級構建塊。包括會話標識符和cookie處理，但不包括HTML模板。像Bottle一樣，CherryPy提供了一種將路由映射到磁盤上的目錄以供靜態文件服務的方法。
建議通過WTForms庫進行擴展。通過第三方擴展程序提供。
CherryPy通常會遵循現有的第三方庫來支持某個功能，而不是嘗試本機提供它。 例如，CherryPy不直接支持WebSocket應用程序，而是通過ws4py庫支持。
CherryPy的文檔包含一個方便的教程，介紹了該程序的各個方面。與其他框架教程不同，它不會引導完成一個完整的端到端應用程序，但它仍然有用。這些文檔提供了有關各種場景中部署的方便說明，包括虛擬主機，通過Apache和Nginx的反向代理以及許多其他方案。
CherryPy在引擎下使用池化線程，更好地支持多線程服務器適配器。如果想嘗試其他方法，CherryPy的非官方第三方分支交換asyncio協程而不是線程。
Falcon
如果正在構建基於REST的API而不是其他任何東西，那么Falcon提供的絕對必要。它的設計精簡而快速，幾乎沒有標准庫之外的依賴關系。
Falcon獲得“輕薄”標簽的原因很大一部分與框架中的代碼行數無關。這是因為Falcon在應用程序上幾乎沒有任何結構。Falcon應用程序所要做的就是指出哪些函數映射到哪些API端點。從給定端點返回JSON只需設置路由並通過Python標准庫中的json.dumps函數從中返回數據。對Python 3的async的支持尚未落入Falcon，但正在努力實現這一目標。
Falcon還采用了理智的開箱即用默認設置，因此安裝時幾乎不需要修改。例如，對於未明確聲明的任何路由，默認情況下會引發404。如果要將錯誤返回給客戶端，可以引發與框架捆綁在一起的許多庫存異常中的一個（例如HTTPBadRequest）或使用泛型falcon.HTTPError異常。如果需要為給定路線進行預處理或后處理，Falcon也會為這些路徑提供掛鈎。
Falcon對API的關注意味着用傳統的HTML用戶界面構建Web應用程序幾乎沒有。例如，表單處理功能和CSRF保護工具幾乎不存在。也就是說，Falcon提供了優雅的選項來擴展其功能，因此可以構建更復雜的項目。除了上面提到的掛鈎機制之外，還可以找到一個用於創建中間件的界面，該界面可用於包裝所有Falcon的API。
Falcon的文檔與其他框架相比比較細長，但僅僅因為它的覆蓋范圍較小。用戶指南包括所有主要功能的正式逐步演練，以及一個快速入門部分，可讓您查看帶或不帶注釋的示例代碼。
Flask
關於Python中的Web框架的大多數討論都是從Flask開始提到的，並且有充分的理由。 Flask是一個成熟的，易於理解的框架，廣泛使用且非常穩定。使用Flask進行輕量級Web項目或基本REST API幾乎不可能出錯，但如果試圖構建更大的東西，將面臨繁重的工作。
Flask的核心吸引力在於其進入門檻低。一個基本的“hello world”Flask應用程序可以在少於10行的Python中設置。廣泛使用的HTML模板系統Jinja2附帶了使渲染文本變得容易的框架，但是Jinja2可以換成任何數量的其他模板引擎（例如Mustache），或者可以自己動手。
簡潔的名稱，Flask默認省略了許多細節。例如，它沒有開箱即用的數據層或ORM，也沒有類似表單驗證的規定。但是，它可以通過擴展進行擴展，其中有幾十個，包括許多常見用例，如緩存，表單處理和驗證，數據庫連接等。這種默認設計允許開始設計具有絕對最小功能的Flask應用程序，然后僅在需要時將所需的部分分層。
Flask的文檔和藹可親，易於閱讀。快速入門文檔非常出色地幫助啟動和運行，同時還解釋了為簡單的Flask應用程序所做的默認選擇的重要性，並且API文檔充滿了如何使用所有內容的良好示例。同樣優秀的是“片段”的集合，這些片段是如何使用Flask完成特定任務的快速和骯臟的示例，例如如果存在如何返回對象，如果不存在則返回404錯誤。
Flask在2018年早些時候發布了它的里程碑1.0版本，Python 2.6和Python 3.3是支持的最低版本，並且它的許多行為最終都是一成不變的。Flask沒有明確支持Python的異步語法，但是為了滿足這種需求，已經剝離了一個名為Quart的與Flask相關的API兼容變體。
Pyramid
小而輕，Pyramid比Django更接近Flask甚至Falcon。因此，它非常適合於將現有Python代碼公開為REST API，或者為開發人員完成大部分繁重任務的Web項目提供核心的任務。
描述Pyramid極簡主義的一個好方法是“無策略”，這是在文檔部分中使用的一個術語，用於討論Pyramid如何與其他Web框架形成對比。你使用什么樣的數據庫或什么樣的模板語言不是金字塔的關注點。
“Pyramid僅提供一種機制來映射URL以查看代碼，”文檔說，“以及一組用於調用這些視圖的約定。可以自由地在您的應用程序中使用符合您需求的第三方組件。“
構建基本的Pyramid應用程序只需要很少的工作。與Bottle和Flask一樣，Pyramid應用程序可以包含單個Python文件，除了框架本身的文件。一個簡單的單路徑API不需要十幾行代碼。其中大部分是來自... import語句和設置WSGI服務器的樣板。
默認情況下，Pyramid包含Web應用程序中常見的幾個項目，但它們是作為要拼接在一起的組件提供的，而不是完整的解決方案。例如，包括對用戶會話的支持，它甚至還帶有CSRF保護。但是對Django提供的用戶帳戶（例如登錄或帳戶管理）的支持不是交易的一部分。您必須自己滾動或通過插件添加它。表單處理和數據庫連接也是如此。
Pyramid避免過於極小的一種方法是通過提供從Pyramid項目制作模板的方法來重用或重新使用先前的工作。這些模板，即Scaffolds，生成一個帶有簡單路由和一些入門HTML / CSS模板的Pyramid應用程序。默認情況下，Pyramid包含的支架包括一個示例啟動項目和一個通過常用的Python庫SQLAlchemy連接到數據庫的項目。
Pyramid在測試和調試工具方面同樣細長。在Pyramid應用程序中捆綁debugtoolbar擴展，將在應用程序生成的每個網頁上獲得一個可點擊圖標，該圖標生成有關應用程序執行的詳細信息，包括發生錯誤時的詳細回溯。還存在記錄和單元測試，即使從這個輕量級的框架中排除兩個看起來也很愚蠢的項目。
Pyramid的文檔很棒。除了快速瀏覽基礎知識和教程式演練之外，還可以找到一組社區貢獻的教程，用於構建各種項目和常用食譜的烹飪手冊。后者包括針對大量目標環境的部署技術，從Google App Engine到Nginx。
Pyramid支持Python 2和Python 3，但不使用Python 3的異步語法。有關如何在Pyramid中利用異步的線索，請參閱aiopyramid項目，其中包括用於異步驅動的“hello world”應用程序的腳手架。
Tornado
Tornado是針對特定用例的另一個小框架。Tornado專為構建異步網絡應用程序而設計，非常適合創建同時打開大量網絡連接並使其保持活動狀態的服務，即涉及WebSockets或長輪詢的任何內容。
像Bottle或Falcon一樣，Tornado省略了與其核心目的無關的特征。例如，Tornado有一個內置的模板系統，用於生成輸出（以HTML或其他方式）和國際化，表單處理，cookie設置，用戶身份驗證和CSRF保護的機制。但是它省略了類似於表單驗證和ORM的功能，它們更適合面向用戶的Web應用程序。
Tornado擅長為需要嚴密控制異步網絡細節的應用程序提供基礎架構。例如，Tornado不僅提供內置的異步HTTP服務器，還提供異步HTTP客戶端。因此，Tornado非常適合構建應用程序，例如Web scraper或bot，它們並行查詢其他站點並對返回的數據進行操作。
如果正在嘗試創建一個使用HTTP以外的協議的應用程序，Tornado會提供幫助。它提供對DNS解析器以及第三方認證服務等實用程序的低級TCP連接和套接字的訪問，並支持通過WSGI標准與其他框架進行互操作。文檔很小但不稀疏，包含了如何完成所有這些的大量示例。
Tornado既利用並補充了Python的異步行為本機功能。如果使用的是Python 3.5，Tornado支持內置的異步和等待關鍵字，它們可以為應用程序提供速度提升。對於早期版本的Python，可以使用yield語句。在任何一種情況下，都可以使用期貨或回調來處理對事件的響應。
Tornado 5.0改進了與Python的本機異步功能的集成。因此不再支持Python 3.3，並且Python 3.5用戶必須使用Python 3.5.2或更高版本。 Tornado 6.0將需要Python 3.5及更高版本，並將完全放棄Python 2支持。
文檔描述為“類BSD”.由同一作者通過單獨的庫提供。支持SQLAlchemy作為標准ORM但不包括在內。Tornado wiki中提供的鏈接。可通過第三方擴展程序獲得。
Tornado還提供了一個同步原語庫，信號量，鎖等，以協調異步協程之間的事件。請注意，與Python解釋器本身一樣，Tornado通常運行單線程，因此這些原語與其線程名稱不同。 但是，如果想在並行進程中運行Tornado以利用多個套接字和內核，那么可以使用這些工具。
Tornado的文檔涵蓋了框架中的每個主要概念以及模型中的所有主要API。 雖然它包含一個示例應用程序（網絡抓取工具），但它主要用於演示Tornado的排隊模塊。
Web.py
Web.py最初是由已故的Aaron Swartz創建的，並被用作Reddit的原始基礎。盡管Reddit可能已經從Web.py轉移，但Web.py繼續由其他人維護，主要是Anand Chitipothu。在范圍和設計上，Web.py類似於Bottle和Flask;你可以把它當作一個基本的骨架，然后在它上面構建，而不會感覺太受限制。
要調用基本的Web.py實例，需要做的就是傳遞一個URL和函數映射列表。 URL可以包含帶有捕獲參數的正則表達式，允許使用/users/RayB或/article/451等格式從URL中提取數據。 Bottle具有類似的機制，但也提供了確保參數符合某些標准的方法（例如，它們只能是整數）。
Web.py在很大程度上保持干凈和朴素，因為它不會嘗試承擔其他機制更好處理的任務。例如，沒有本機功能允許從Web.py堆棧提供靜態內容；說明明智地建議改為通過Web服務器。相比之下，Bottle具有提供靜態內容的本機功能，盡管它是可選的。 Web.py還包括cookie和會話管理，甚至還有一個簡單的輸出緩存。
Web.py有一個HTML模板系統;它是非常基本的，但允許if/then/else邏輯。更復雜，更有用的是Web.py的動態生成HTML表單的系統，具有CSS樣式的類屬性和基本的表單驗證機制。如果希望使用以編程方式生成的表單（例如基本數據庫資源管理器）生成應用程序，這將非常方便。
Web.py的文檔與框架本身一樣小，但它並沒有提供相關的示例。 “cookbook”部分（多種語言，不低於）演示了許多常見用例（提供靜態內容，逐步傳輸大型文件等）。甚至還有一個使用該框架構建的真實Web應用程序庫，其中許多都帶有源代碼。
請注意，Web.py並未像其他框架一樣保持與Python 3兼容性的最新狀態。這不僅意味着缺乏對異步語法的支持，還意味着缺少對已棄用的函數的錯誤。此外，目前尚不清楚維護者是否有計划在Python 2到達其支持生命周期結束后保持Web.py的最新狀態。
Wheezy.web
Wheezy.web是Web框架的Flask/Bottle/Pyramid模型：小巧輕便，專注於提供高速和高並發性。這個功能集的核心是小的，但它的創建者已經為它配備了各種必備功能。
談論Wheezy.web作為單一產品有點誤導。Wheezy.web將同一作者創建的其他幾個庫粘合在一起，每個庫根據希望應用程序的操作提供不同的服務。例如，Wheezy.http庫被Wheezy.web大量用於許多基本行為，但除非應用程序必須執行用戶身份驗證，否則不需要Wheezy.security庫。
這種庫集合方法意味着使用Wheezy開發的最簡單方法是從PyPI安裝它或使用easy_install來收集所有相關的包。我在Python 3.51中使用easy_install時遇到了問題，但它在Python 2.7中運行良好。
Wheezy.web的核心主要是將路由映射到函數和處理重定向，但它配備了一些其他有用的功能。例如，使用@secure裝飾器標記的任何路由將僅接受HTTPS請求，並且如果進行HTTP連接嘗試將重定向到HTTPS。另一個核心添加是中間件，以便可以自定義路徑路由和HTTP錯誤。
Wheezy的其他庫涵蓋了一組相當豐富的用例。Wheezy.validation可以幫助確保提交的數據滿足特定條件，例如，用戶名或密碼滿足長度或復雜性要求。Wheezy.caching允許緩存未更改的響應以加速處理，Wheezy.captcha與Python的PIL/Pillow圖像庫集成以生成驗證碼。對於國際化，它與標准GNU gettext實用程序集成。
核心Wheezy.web框架不包含模板引擎。如果需要做的不僅僅是返回純文本或JSON，可以添加Wheezy.template引擎或連接許多第三方引擎，如Jinja2和Mako。 Wheezy.web也省略了ORM; Wheezy文檔中的示例通過手動SQL字符串使用SQLite。
使用Wheezy構建應用程序需要比使用Flask或Bottle更多的樣板，但不要過分；其中大部分涉及設置路線和中間件，這些東西可以在不費力的情況下抽象出來。Wheezy的文檔中詳細解釋了這些細節，其中包括“創建留言簿”教程，但其他方面則是關於獎金的。
Wheezy的開發似乎已經停滯不前，因為該項目的最后一次提交都記錄在2015年。這對於保持與新Python功能的兼容性並不是好兆頭。
權衡Python Web框架選項
選擇Python Web框架與選擇任何其他軟件工具沒什么不同：它完全是為了適應目標和適應自己的開發習慣和偏好。
如果更喜歡minimal，只需創建一個REST API或在Web框架中包裝現有的Python代碼，這里描述的許多Python框架都非常適合你的需求。在這方面，Flask和Bottle是很好的選擇。由於其緊湊性，Bottle特別適合包含在其他項目中。
Pyramid和CherryPy的項目結構相對較少，因此它們對於快速包裝現有代碼非常有用。在這方面，Falcon和Tornado更加微弱。它們的開銷很小，但也缺乏更強大的Web應用程序所需的更重的工具。 Web.py是涉及用戶交互（例如表單提交）的應用程序的快速起點。 Wheezy.web和它的庫允許按照自己想要的功能去做。
對於具有更高端需求的開發人員而言，Django是最好的起點之一，不僅因為其擁有豐富的開箱即用組件，而且龐大的用戶社區多年來取得了巨大成功。如果你不需要這樣的完整性，Weppy是一個很好的折衷方案，因為它比更小的框架具有更多擴展的功能集。
最后，雖然CubicWeb和Zope2僅提供整個開發環境而不是框架，但它們都是頭重腳輕和特殊的。使用它們是以學習它們的特性為代價的。
原文鏈接：
https://www.infoworld.com/article/3105502/python/review-13-python-web-frameworks-compared.html
Python的gevent帶來的非阻塞IO和coroutine同步方式封裝異步，足以完爆Twisted；
Nodejs的特性也就是非阻塞IO和更快語言解釋器，但是基於事件編程模式更合適對用戶響應方式的前端，不太合適大部分是RPC或循環方式的服務端邏輯；
現在分布式和SMP架構下 gevent多進程+coroutine+簡潔的語言特性+容易C/C++性能擴展絕對是理想選擇。
tornado的coroutine跟greenlet略有區別，跟asyncio里的協程類似。本質上來說只是把本來需要拆成多個callback的代碼合進了一個生成器，生成器不斷yield一系列的Future對象，調度器在Future完成時通過調用生成器的send方法喚醒協程，實現執行-等待-執行-等待的邏輯，而從全局看，所有協程共享一個線程，一個協程等待的時候調度器會插入其他協程進行執行。通過gen修飾的協程本身也會返回一個Future，這個Future在協程返回時完成，等待這個Future就可以達到等待協程執行結束的效果。