Flask源码剖析详解

1. 前言

本文将基于flask 0.1版本(git checkout 8605cc3)来分析flask的实现，试图理清flask中的一些概念，加深读者对flask的理解，提升对flask的认识。从而，在使用flask过程当中，可以减小困惑，成竹在胸，遇bug而不惊。

 

在试图理解flask的设计以前，你知道应该知道如下几个概念：

• flask(web框架)是什么
• WSGI是什么
• jinja2是什么
• Werkzeug是什么

本文将首先回答这些问题，而后再分析flask源码。

2. 知识准备

2.1 WSGI

下面这张图来自这里，经过这张图，读者对web框架所处的位置和WSGI协议可以有一个感性的认识。

WSGI

wikipedia上对WSGI的解释就比较通俗易懂。为了更好的理解WSGI，咱们来看一个例子:

from eventlet import wsgi import eventlet def hello_world(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) return ['Hello, World!\r\n'] wsgi.server(eventlet.listen(('', 8090)), hello_world) 

咱们定义了一个hello_world函数，这个函数接受两个参数。分别是environ和start_response，咱们将这个hello_world传递给eventlet.wsgi.server之后， eventlet.wsgi.server在调用hello_world时，会自动传入environ和start_response这两个参数，并接受hello_world的返回值。而这，就是WSGI的做用。

也就是说，在python的世界里，经过WSGI约定了web服务器怎么调用web应用程序的代码，web应用程序须要符合什么样的规范，只要web应用程序和web服务器都遵照WSGI 协议，那么，web应用程序和web服务器就能够随意的组合。这也就是WSGI存在的缘由。

WSGI是一种协议，这里，须要注意两个相近的概念：

• uwsgi同WSGI同样是一种协议
• 而uWSGI是实现了uwsgi和WSGI两种协议的web服务器

2.2 jinja2与Werkzeug

flask依赖jinja2和Werkzeug，为了彻底理解flask，咱们还须要简单介绍一下这两个依赖。

jinja2

Jinja2是一个功能齐全的模板引擎。它有完整的unicode支持，一个可选 的集成沙箱执行环境，被普遍使用。

jinja2的一个简单示例以下:

>>> from jinja2 import Template >>> template = Template('Hello !') >>> template.render(name='John Doe') u'Hello John Doe!' 

Werkzeug

Werkzeug是一个WSGI工具包，它能够做为web框架的底层库。

我发现Werkzeug的官方文档介绍特别好，下面这一段摘录自这里。

Werkzeug是一个WSGI工具包。WSGI是一个web应用和服务器通讯的协议，web应用能够经过WSGI一块儿工做。一个基本的”Hello World”WSGI应用看起来是这样的:

def application(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) return ['Hello World!'] 

上面这小段代码就是WSGI协议的约定，它有一个可调用的start_response 。environ包含了全部进来的信息。 start_response用来代表已经收到一个响应。 经过Werkzeug，咱们能够没必要直接处理请求或者响应这些底层的东西，它已经为咱们封装好了这些。

请求数据须要environ对象，Werkzeug容许咱们以一个轻松的方式访问数据。响应对象是一个WSGI应用，提供了更好的方法来建立响应。以下所示：

from werkzeug.wrappers import Response def application(environ, start_response): response = Response('Hello World!', mimetype='text/plain') return response(environ, start_response) 

2.3 如何理解wsgi, Werkzeug, flask之间的关系

Flask是一个基于Python开发而且依赖jinja2模板和Werkzeug WSGI服务的一个微型框架，对于Werkzeug，它只是工具包，其用于接收http请求并对请求进行预处理，而后触发Flask框架，开发人员基于Flask框架提供的功能对请求进行相应的处理，并返回给用户，若是要返回给用户复杂的内容时，须要借助jinja2模板来实现对模板的处理。将模板和数据进行渲染，将渲染后的字符串返回给用户浏览器。

2.4 Flask是什么，不是什么

Flask永远不会包含数据库层，也不会有表单库或是这个方面的其它东西。Flask自己只是Werkzeug和Jinja2的之间的桥梁，前者实现一个合适的WSGI应用，后者处理模板。固然，Flask也绑定了一些通用的标准库包，好比logging。除此以外其它全部一切都交给扩展来实现。

为何呢？由于人们有不一样的偏好和需求，Flask不可能把全部的需求都囊括在核内心。大多数web应用会须要一个模板引擎。然而不是每一个应用都须要一个SQL数据库的。

Flask 的理念是为全部应用创建一个良好的基础，其他的一切都取决于你本身或者 扩展。

3. Flask源码分析

Flask的使用很是简单，官网的例子以下：

from flask import Flask app = Flask(__name__) @app.route("/") def hello(): return "Hello World!" if __name__ == "__main__": app.run() 

每当咱们须要建立一个flask应用时，咱们都会建立一个Flask对象:

app = Flask(__name__) 

下面看一下Flask对象的__init__方法，若是不考虑jinja2相关，核心成员就下面几个:

class Flask: def __init__(self, package_name): self.package_name = package_name self.root_path = _get_package_path(self.package_name) self.view_functions = {} self.error_handlers = {} self.before_request_funcs = [] self.after_request_funcs = [] self.url_map = Map() 

咱们把目光汇集到后面几个成员，view_functions中保存了视图函数(处理用户请求的函数，如上面的hello())，error_handlers中保存了错误处理函数，before_request_funcs和after_request_funcs保存了请求的预处理函数和后处理函数。

self.url_map用以保存URI到视图函数的映射，即保存app.route()这个装饰器的信息，以下所示：

def route(...): def decorator(f): self.add_url_rule(rule, f.__name__, **options) self.view_functions[f.__name__] = f return f return decorator 

上面说到的是初始化部分，下面看一下执行部分，当咱们执行app.run()时，调用堆栈以下:

app.run() run_simple(host, port, self, **options) __call__(self, environ, start_response) wsgi_app(self, environ, start_response) 

wsgi_app是flask核心:

def wsgi_app(self, environ, start_response): with self.request_context(environ): rv = self.preprocess_request() if rv is None: rv = self.dispatch_request() response = self.make_response(rv) response = self.process_response(response) return response(environ, start_response) 

能够看到，wsgi_app这个函数的做用就是先调用全部的预处理函数，而后分发请求，再调用全部后处理函数，最后返回response。

看一下dispatch_request函数的实现，由于，这里有flask的错误处理逻辑:

def dispatch_request(self): try: endpoint, values = self.match_request() return self.view_functions[endpoint](**values) except HTTPException, e: handler = self.error_handlers.get(e.code) if handler is None: return e return handler(e) except Exception, e: handler = self.error_handlers.get(500) if self.debug or handler is None: raise return handler(e) 

若是出现错误，则根据相应的error code，调用不一样的错误处理函数。

上面这段简单的源码分析，就已经将Flask几个核心变量和核心函数串联起来了。其实，咱们这里扣出来的几段代码，也就是Flask的核心代码。毕竟，Flask的0.1版本包含大量注释之后，也才六百行代码。

4. flask的魔法

若是读者打开flask.py文件，将看到我前面的源码分析几乎已经覆盖了全部重要的代码。可是，细心的读者会看到，在Flask.py文件的末尾处，有如下几行代码:

# context locals _request_ctx_stack = LocalStack() current_app = LocalProxy(lambda: _request_ctx_stack.top.app) request = LocalProxy(lambda: _request_ctx_stack.top.request) session = LocalProxy(lambda: _request_ctx_stack.top.session) g = LocalProxy(lambda: _request_ctx_stack.top.g) 

这是咱们得以方便的使用flask开发的魔法，也是flask源码中的难点。在分析以前，咱们先看一下它们的做用。

在flask的开发过程当中，咱们能够经过以下方式访问url中的参数:

from flask import request @app.route('/') def hello(): name = request.args.get('name', None) 

看起来request像是一个全局变量，那么，一个全局变量为何能够在一个多线程环境中随意使用呢，下面就随我来一探究竟吧！

先看一下全局变量_request_ctx_stack的定义:

_request_ctx_stack = LocalStack() 

正如它LocalStack()的名字所暗示的那样，_request_ctx_stack是一个栈。显然，一个栈确定会有push 、pop和top函数，以下所示:

class LocalStack(object): def __init__(self): self._local = Local() def push(self, obj): rv = getattr(self._local, 'stack', None) if rv is None: self._local.stack = rv = [] rv.append(obj) return rv def pop(self): stack = getattr(self._local, 'stack', None) if stack is None: return None elif len(stack) == 1: release_local(self._local) return stack[-1] else: return stack.pop() 

按照咱们的理解，要实现一个栈，那么LocalStack类应该有一个成员变量，是一个list，而后经过 这个list来保存栈的元素。然而，LocalStack并无一个类型是list的成员变量， LocalStack仅有一个成员变量self._local = Local()。

顺藤摸瓜，咱们来到了Werkzeug的源码中，到达了Local类的定义处:

class Local(object): def __init__(self): object.__setattr__(self, '__storage__', {}) object.__setattr__(self, '__ident_func__', get_ident) def __getattr__(self, name): try: return self.__storage__[self.__ident_func__()][name] except KeyError: raise AttributeError(name) def __setattr__(self, name, value): ident = self.__ident_func__() storage = self.__storage__ try: storage[ident][name] = value except KeyError: storage[ident] = {name: value} 

须要注意的是，Local类有两个成员变量，分别是__storage__和__ident_func__，其中，前者 是一个字典，后者是一个函数。这个函数的含义是，获取当前线程的id（或协程的id）。

此外，咱们注意到，Local类自定义了__getattr__和__setattr__这两个方法，也就是说，咱们在操做self.local.stack时， 会调用__setattr__和__getattr__方法。

_request_ctx_stack = LocalStack() _request_ctx_stack.push(item) # 注意，这里赋值的时候，会调用__setattr__方法 self._local.stack = rv = [] ==> __setattr__(self, name, value) 

而__setattr的定义以下:

def __setattr__(self, name, value): ident = self.__ident_func__() storage = self.__storage__ try: storage[ident][name] = value except KeyError: storage[ident] = {name: value} 

在__setattr__中，经过__ident_func__获取到了一个key，而后进行赋值。自此，咱们能够知道， LocalStack是一个全局字典，或者说是一个名字空间。这个名字空间是全部线程共享的。 当咱们访问字典中的某个元素的时候，会经过__getattr__进行访问，__getattr__先经过线程id， 找当前这个线程的数据，而后进行访问。

字段的内容以下：

{'thread_id':{'stack':[]}} {'thread_id1':{'stack':[_RequestContext()]}, 'thread_id2':{'stack':[_RequestContext()]}} 

最后，咱们来看一下其余几个全局变量:

current_app = LocalProxy(lambda: _request_ctx_stack.top.app) request = LocalProxy(lambda: _request_ctx_stack.top.request) session = LocalProxy(lambda: _request_ctx_stack.top.session) g = LocalProxy(lambda: _request_ctx_stack.top.g) 

读者能够自行看一下LocalProxy的源码，LocalProxy仅仅是一个代理（能够想象设计模式中的代理模式）。

经过LocalStack和LocalProxy这样的Python魔法，每一个线程访问当前请求中的数据(request, session)时， 都好像都在访问一个全局变量，可是，互相之间又互不影响。这就是Flask为咱们提供的便利，也是咱们 选择Flask的理由！

5. 总结

在这篇文章中，咱们简单地介绍了WSGI, jinja2和Werkzeug，详细介绍了Flask在web开发中所处的位置和发挥的做用。最后，深刻Flask的源码，了解了Flask的实现。