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不直接支援Socket/">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