Flask源码剖析详解
1. 前⾔
本⽂将基于版本(git checkout 8605cc3)来分析flask的实现，试图理清flask中的⼀些概念，加深读者对flask的理解，提⾼对flask的认识。从⽽，在使⽤flask过程中，能够减少困惑，胸有成⽵，遇bug⽽不惊。
在试图理解flask的设计之前，你知道应该知道以下⼏个概念：
flask(web框架)是什么
WSGI是什么
jinja2是什么
Werkzeug是什么
本⽂将⾸先回答这些问题，然后再分析flask源码。
2. 知识准备
2.1 WSGI
下⾯这张图来⾃，通过这张图，读者对web框架所处的位置和WSGI协议能够有⼀个感性的认识。
WSGI
上对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
是⼀个功能齐全的模板引擎。它有完整的unicode⽀持，⼀个可选的集成沙箱执⾏环境，被⼴泛使⽤。
jinja2的⼀个简单⽰例如下:
>>> from jinja2 import Template
>>> template = Template('Hello !')
>>> der(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本⾝只是Werkzeug和Jinja2的之间的桥梁，前者实现⼀个合适的WSGI应⽤，后者处理模板。当然，Flask也绑定了⼀些通⽤的标准库包，⽐如logging。除此之外其它所有⼀切都交给扩展来实现。
为什么呢？因为⼈们有不同的偏好和需求，Flask不可能把所有的需求都囊括在核⼼⾥。⼤多数web应⽤会需要⼀个模板引擎。然⽽不是每个应⽤都需要⼀个SQL数据库的。
Flask 的理念是为所有应⽤建⽴⼀个良好的基础，其余的⼀切都取决于你⾃⼰或者扩展。
3. Flask源码分析
Flask的使⽤⾮常简单，官⽹的例⼦如下：
from flask import Flask
app = Flask(__name__)
@ute("/")
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
<_path = _get_package_path(self.package_name)
self.view_functions = {}
<_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到视图函数的映射，即保存ute()这个装饰器的信息，如下所⽰：
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):
quest_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 = _(e.code)
if handler is None:
return e
return handler(e)
except Exception, e:
handler = _(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_p.app)
request = LocalProxy(lambda: _request_p.request)
session = LocalProxy(lambda: _request_p.session)
g = LocalProxy(lambda: _request_p.g)
这是我们得以⽅便的使⽤flask开发的魔法，也是flask源码中的难点。在分析之前，我们先看⼀下它们的作⽤。
在flask的开发过程中，我们可以通过如下⽅式访问url中的参数:
from flask import request
@ute('/')
def hello():
name = ('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)
flask下载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_p.app)
request = LocalProxy(lambda: _request_p.request)
session = LocalProxy(lambda: _request_p.session)
g = LocalProxy(lambda: _request_p.g)
读者可以⾃⾏看⼀下LocalProxy的源码，LocalProxy仅仅是⼀个代理（可以想象设计模式中的代理模式）。
通过LocalStack和LocalProxy这样的Python魔法，每个线程访问当前请求中的数据(request, session)时，都好像都在访问⼀个全局变量，但是，互相之间⼜互不影响。这就是Flask为我们提供的便利，也是我们选择Flask的理由！
5. 总结
在这篇⽂章中，我们简单地介绍了WSGI, jinja2和Werkzeug，详细介绍了Flask在web开发中所处的位置和发挥的作⽤。最后，深⼊Flask的源码，了解了Flask的实现。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。