Django,Flask,Tornado三大框架對比，Python幾種主流框架，13個Python web框架比較，2018年Python web五大主流框架

從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編寫的，輕量級的，簡單輕巧，而且使用起來很是的方便。

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就能夠達到等待協程執行結束的效果。

Django,Flask,Tornado三大框架對比，Python幾種主流框架，13個Python web框架比較，2018年Python web五大主流框架

Django請求流程

Python幾種主流框架

2018年Python web五大主流框架

13個Python web框架比較