Python 有哪些好的 Web 框架

2023-03-04 17:14:02Python010

Python 有哪些好的 Web 框架,第1张

浅谈五大Python Web框架

说到Web Framework，Ruby的世界Rails一统江湖，而Python则是一个百花齐放的世界，各种micro-framework、framework不可胜数。

虽然另一大脚本语言PHP也有不少框架，但远没有Python这么夸张，也正是因为Python Web Framework（Python Web开发框架，以下简称Python框架）太多，所以在Python社区总有关于Python框架孰优孰劣的话题，讨论的时间跨度甚至长达3-5年。

Python这么多框架，能挨个玩个遍的人不多，坦白的说我也只用过其中的三个开发过项目，另外一些稍微接触过，所以这里只能浅谈一下。

Django，Python框架虽然说是百花齐放，但仍然有那么一家是最大的，它就是Django。要说Django是Python框架里最好的，有人同意也有人坚决反对，但说Django的文档最完善、市场占有率最高、招聘职位最多估计大家都没什么意见。Django为人所称道的地方主要有：完美的文档，Django的成功，我觉得很大一部分原因要归功于Django近乎完美的官方文档（包括Django book）。

全套的解决方案，Django象Rails一样，提供全套的解决方案（full-stack framework + batteries included），基本要什么有什么（比如：cache、session、feed、orm、geo、auth），而且全部Django自己造，开发网站应手的工具Django基本都给你做好了，因此开发效率是不用说的，出了问题也算好找，不在你的代码里就在Django的源码里。

强大的URL路由配置，Django让你可以设计出非常优雅的URL，在Django里你基本可以跟丑陋的GET参数说拜拜。自助管理后台，admin interface是Django里比较吸引眼球的一项contrib，让你几乎不用写一行代码就拥有一个完整的后台管理界面。

而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。URL配置虽然强大，但全部要手写，这一点跟Rails的Convention over configuration的理念完全相左，高手和初识Django的人配出来的URL会有很大差异。

让人纠结的auth模块，Django的auth跟其它模块结合紧密，功能也挺强的，就是做的有点过了，用户的数据库schema都给你定好了，这样问题就来了，比如很多网站要求email地址唯一，可schema里这个字段的值不是唯一的，纠结是必须的了。

Python文件做配置文件，而不是更常见的ini、xml或yaml等形式。这本身不是什么问题，可是因为理论上来说settings的值是能够动态的改变的（虽然大家不会这么干），但这不是最佳实践的体现。总的来说，Django大包大揽，用它来快速开发一些Web运用是很不错的。如果你顺着Django的设计哲学来，你会觉得Django很好用，越用越顺手；相反，你如果不能融入或接受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的版本，应该跟这条有关系。

最后关于框架选择的误区在框架的选择问题上，许多人很容易就陷入了下面两个误区中而不自知：

1. 哪个框架最好——世上没有最好的框架，只有最适合你自己、最适合你的团队的框架。编程语言选择也是一个道理，你的团队Python最熟就用Python好了，如果最熟悉的是Ruby那就用Ruby好了，编程语言、框架都只是工具，能多、快、好、省的干完活就是好东西。 2. 过分关注性能——其实大部分人是没必要太关心框架的性能的，因为你开发的网站根本就是个小站，能上1万的IP的网站已经不多了，上10万的更是很少很少。在没有一定的访问量前谈性能其实是没有多大意义的，因为你的CPU和内存一直就闲着呢。而且语言和框架一般也不会是性能瓶颈，性能问题最常出现在数据库访问和文件读写上。 PHP的Zend Framework是出了名的慢，但是Zend Framework一样有大站，如：digg.com；常被人说有性能问题的Ruby和Rails，不是照样可以开发出twitter吗？再者现在的硬件、带宽成本其实是很低的，特别有了云计算平台后，人力成本才是最贵的，没有上万的IP根本就不用太在意性能问题，流量上去了花点钱买点服务器空间好了，简单快速的解决性能问题。注：前面有网友质疑我“Quora是用Pylons开发的”这样的说法不客观，特说明一下，这里所说的某个网站A是用B开发的，只是指A主要或部分是由B开发的，大家就不要再去纠结A还用C了。

关于python web，建议多学习一下大神的案例。从里面提取精髓的东西加以吸收，Python学习指南请看下面的代码

learning = input('Do you want to learn Python now(Yes or No):')

a = str(learning)

if a == 'Yes':

print('QQ1129834903')

else:

print('Thanks!!')

用Python做Web开发，Django框架是个非常好的起点。

Django是一个开放源代码的Web应用框架，由Python写成。采用了MTV的框架模式，即模型M，视图V和模版T。它最初是被开发来用

于管理劳伦斯出版集团旗下的一些以新闻内容为主的网站的，即是CMS（内容管理系统）软件。并于2005年7月在BSD许可证下发布。

Django已经成为web开发者的首选框架，是一个遵循 MVC 设计模式的框架。MVC是Model、View、Controller三个单词的简写，分别

代表模型、视图、控制器。Django其实也是一个MTV 的设计模式。MTV是Model、Template、View三个单词的简写，分别代表模型、

模版、视图。但是在Django中，控制器接受用户输入的部分由框架自行处理，所以 Django 里更关注的是模型（Model）、模板

(Template)和视图（Views），称为 MTV模式。

Django 视图不处理用户输入，而仅仅决定要展现哪些数据给用户，而Django 模板仅仅决定如何展现Django视图指定的数据。或者说,

Django将MVC中的视图进一步分解为 Django视图和 Django模板两个部分，分别决定 “展现哪些数据” 和 “如何展现”，使得

Django的模板可以根据需要随时替换，而不仅仅限制于内置的模板。

至于MVC控制器部分，由Django框架的URLconf来实现。URLconf机制是使用正则表达式匹配URL，然后调用合适的Python函数。

URLconf对于URL的规则没有任何限制，你完全可以设计成任意的URL风格，不管是传统的，RESTful的，或者是另类的。框架把控制层

给封装了，无非与数据交互这层都是数据库表的读,写,删除,更新的操作。在写程序的时候，只要调用相应的方法就行了，感觉很方便。程

序员把控制层东西交给Django自动完成了。只需要编写非常少的代码完成很多的事情。所以，它比MVC框架考虑的问题要深一步，因为

我们程序员大都在写控制层的程序。这个工作交给了框架，仅需写很少的调用代码，大大提高了工作效率。

更多技术请关注Python视频教程。

造轮子是最好的一种学习方式，本文尝试从0开始造个Python Web框架的轮子，我称它为 ToyWebF 。

本文操作环境为：MacOS，文中涉及的命令，请根据自己的系统进行替换。

ToyWebF的简单特性：

下面我们来实现这些特性。

首先，我们需要安装gunicorn，回忆一下Flask框架，该框架有内置的Web服务器，但不稳定，所以上线时通常会替换成uWSGI或gunicorn，这里不搞这个内置Web服务，直接使用gunicorn。

我们创建新的目录与Python虚拟环境，在该虚拟环境中安装gunicorn

在啥都没有的情况下，构建最简单的Web服务，在ToyWebF目录下，创建app.py与api.py文件，写入下面代码。

运行 gunicorn app:app 访问 http://127.0.0.1:8000 ，可以看见 Hello, World! ，但现在请求体中的参数在environ变量中，难以解析，我们返回的response也是bytes形式。

我们可以使用webob库，将environ中的数据转为Request对象，将需要返回的数据转为Response对象，处理起来更加直观方便，直接通过pip安装一下。

然后修改一下API类的 __call__方法，代码如下。

上述代码中，通过webob库的Request类将environ对象（请求的环境信息）转为容易处理的request，随后调用handle_request方法对request进行处理，处理的结果，通过response对象返回。

handle_request方法在ToyWebF中非常重要，它会匹配出某个路由对应的处理方法，然后调用该方法处理请求并将处理的结果返回，在解析handle_request前，需要先讨论路由注册实现，代码如下。

其实就是将路由和方法存到self.routes字典中，可以通过route装饰器的形式将路由和方法关联，也可以通过add_route方法关联，在app.py中使用一下。

因为url中可以存在变量，如 @app.route("/hello/{name}") ，所以在匹配时，需要进行解析，可以使用正则匹配的方式进行匹配，parse这个第三方库已经帮我们实现了相应的正则匹配逻辑，pip安装使用一下则可。

这里定义find_handler方法来实现对self.routes的遍历。

了解了路由与方法关联的原理后，就可以实现handle_request方法，该方法主要的路径就是根据路由调度对应的方法，代码如下。

在该方法中，首先实例化webob库的Response对象，然后通过self.find_handler方法获取此次请求路由对应的方法和对应的参数，比如。

它将返回hello方法对象和name参数，如果是 /hello/二两，那么name就是二两。

因为route装饰器可能装饰器的类对象，比如。

此时self.find_handler方法返回的hanler就是个类，但我们希望调用的是类中的get、post、delete等方法，所以需要一个简单的判断逻辑，通过inspect.isclass方法判断handler如果是类对象，那么就通过getattr方法获取类对象实例的中对应的请求方法。

如果类对象中没有该方法属性，则抛出该请求类型不被允许的错误，如果不是类对象或类对象中存在该方法属性，则直接调用则可。

此外，如果方法的路由并没有注册到self.routes中，即404的情况，定义了defalut_response方法返回其中内容，代码如下。

如果handle_request方法中调度的过程出现问题，则直接raise将错误抛出。

至此，一个最简单的web服务就编写完成了。

回顾Flask，Flask可以支持HTML、CSS、JavaScript等静态文件，利用模板语言，可以构建出简单但美观的Web应用，我们让TopWebF也支持这一功能，最终实现图中的网站，完美兼容静态文件。

Flask使用了jinja2作为其html模板引擎，ToyWebF同样使用jinja2，jinja2其实实现一种简单的DSL（领域内语言），让我们可以在HTML中通过特殊的语法改变HTML的结构，该项目非常值得研究学习。

首先 pip install jinja2 ，然后就可以使用它了，在ToyWebF项目目录中创建templates目录，以该目录作为默认的HTML文件根目录，代码如下。

首先利用jinja2的FileSystemLoader类将file system中的某个文件夹作为loader，然后初始化Environment。

在使用的过程中（即调用template方法），通过get_template方法获得具体的某个模板并通过render方法将对应的内容传递给模板中的变量。

这里我们不写前端代码，直接去互联网中下载模板，这里下载了Bootstrap提供的免费模板，可以自行去 https://startbootstrap.com/themes/freelancer/ 下载，下载完后，你会获得index.html以及对应的css、jss、img等文件，将index.html移动到ToyWebF/templates中并简单修改了一下，添加一些变量。

然后在app.py文件中为index.html定义路由以及需要的参数。

至此html文件的支持就完成了，但此时的html无法正常载入css和js，导致页面布局非常丑陋且交互无法使用。

接着就让ToyWebF支持css、js，首先在ToyWebF目录下创建static文件夹用于存放css、js或img等静态文件，随后直接将前面下载的模板，其中的静态文件复制到static中则可。

通过whitenoise第三方库，可以通过简单的几行代码让web框架支持css和js，不需要依赖nginx等服务，首先 pip install whitenoise ，随后修改API类的 __init__ 方法，代码如下。

其实就是通过WhiteNoise将self.wsgi_app方法包裹起来，在调用API的 __call__ 方法时，直接调用self.whitenoise。

此时，如果请求web服务获取css、js等静态资源，WhiteNoise会获取其内容并返回给client，它在背后会匹配静态资源在系统中对应的文件并将其读取返回。

至此，一开始的网页效果就实现好了。

web服务如果出现500时，默认会返回 internal server error ，这显得比较丑，为了让框架使用者可以自定义500时返回的错误，需要添加一些代码。

首先API初始化时，初始self.exception_handler对象并定义对应的方法添加自定义的错误

在handler_request方法进行请求调度时，调度的方法执行逻辑时报500，此时不再默认将错误抛出，而是先判断是否有自定义错误处理。

在app.py中，自定义错误返回方法，如下。

custom_exception_handler方法只返回自定义的一段话，你完全可以替换成美观的template。

我们可以实验性定义一个路由来看效果。

Web服务的中间件也可以理解成钩子，即在请求前可以对请求做一些处理或者返回Response前对Response做一下处理。

为了支持中间件，在TopWebF目录下创建middleware.py文件，在编写代码前，思考一下如何实现？

回顾一下现在请求的调度逻辑。

1.通过routes装饰器关联路由和方法 2.通过API.whitenoise处理 3.如果是请求API接口，那么会将参数传递给API.wsgi_app 4.API.wsgi_app最终会调用API.handle_request方法获取路由对应的方法并调用该方法执行相应的逻辑

如果希望在request前以及response后做相应的操作，那么其实就需要让逻辑在API.handle_request前后执行，看一下代码。

其中add方法会实例化Middleware对象，该对象会将当前的API类实例包裹起来。

Middleware.handle_request方法其实就是在self.app.handle_request前调用self.process_request方法处理request前的数据以及调用self.process_response处理response后的数据，而核心的调度逻辑，依旧交由API.handle_request方法进行处理。

这里的代码可能会让人感到疑惑， __call__ 方法和handle_request方法中都有self.app.handle_request(request)，但其调用对象似乎不同？这个问题暂时放一下，先继续完善代码，然后再回来解释。

接着在api.py中为API创建middleware属性以及添加新中间件的方法。

随后，在app.py中，自定义一个简单的中间件，然后调用add_middleware方法将其添加。

定义好中间件后，在请求调度时，就需要使用中间件，为了兼容静态文件的情况，需要对css、js、ing文件的请求路径做一下兼容，在其路径中加上/static前缀

紧接着，修改API的 __call__ ，兼容中间件和静态文件，代码如下。

至此，中间件的逻辑就完成了。

但代码中依旧有疑惑，Middleware类中的 __call__ 方法和handle_request方法其调用的self.app到底是谁？

为了方便理解，这里一步步拆解。

如果没有添加新的中间件，那么请求的调度逻辑如下。

在没有添加中间件的情况下，self.app其实就是API本身，所以 middleware.__call__ 中的self.app.handle_request就是调用API.handle_request。

如果添加了新的中间件，如上述代码中添加了名为SimpleCustomMiddleware的中间件，此时的请求调度逻辑如下。

因为注册中间件时，Middleware.add方法替换了原始Middleware实例中的app对象，将其替换成了SimpleCustomMiddleware，而SimpleCustomMiddleware也有app对象，SimpleCustomMiddleware中的app对象，才是API类实例。