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就能够达到等待协程执行结束的效果。