from flask import request
Flask 是一个人气非常高的Python Web框架，笔者也拿它写过一些大大小小的项目，Flask 有一个特性我非常的喜欢，就是无论在什么地方，如果你想要获取当前的request对象，只要 简单的：
从当前request获取内容：
- method： 起始行，元数据
- host： 起始行，元数据
- path： 起始行，元数据
- environ： 其中的 SERVER_PROTOCOL 是起始行，元数据
- headers： 头，元数据
- data： body， 元数据
- remote_addr： 客户端地址
- args： 请求链接中的参数（GET 参数），解析后
- form： form 提交中的参数，解析后
- values： args 和 forms 的集合
- json： json 格式的 body 数据，解析后
- cookies： 指向 Cookie 的链接
Request 对象对参数的分类很细，注意 args, form, valeus, json 的区别。当然最保险也最原始的方式就是自己去解析 data。
另一个需注意的地方是某些属性的类型，并不是 Python 标准的 dict ，而是 MultiDict 或者 CombinedMultiDict。这是为了应对 HTTP 协议中参数都是可重复的这点而做的设定。因此取值的时候要注意这些对象的特性，比如 .get() 和 .get_list() 方法返回的东西是不同的。
非常简单好记，用起来也非常的友好。不过，简单的背后藏的实现可就稍微有一些复杂了。 跟随我的文章来看看其中的奥秘吧！
两个疑问？
在我们往下看之前，我们先提出两个疑问：
疑问一 : request ，看上去只像是一个静态的类实例，我们为什么可以直接使用request.args 这样的表达式来获取当前request的args属性，而不用使用比如：
|
1
2
3
4
5
|
from
flask
import
get_request
# 获取当前request
request
=
get_request()
get_request().args
|
这样的方式呢？flask是怎么把request对应到当前的请求对象的呢？
疑问二 : 在真正的生产环境中，同一个工作进程下面可能有很多个线程（又或者是协程）， 就像我刚刚所说的，request这个类实例是怎么在这样的环境下正常工作的呢？
要知道其中的秘密，我们只能从flask的源码开始看了。
源码，源码，还是源码
首先我们打开flask的源码，从最开始的__init__.py来看看request是怎么出来的：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
# File: flask/__init__.py
from
.
globals
import
current_app, g, request, session, _request_ctx_stack
# File: flask/globals.py
from
functools
import
partial
from
werkzeug.local
import
LocalStack, LocalProxy
def
_lookup_req_object(name):
top
=
_request_ctx_stack.top
if
top
is
None
:
raise
RuntimeError(
'working outside of request context'
)
return
getattr
(top, name)
# context locals
_request_ctx_stack
=
LocalStack()
request
=
LocalProxy(partial(_lookup_req_object,
'request'
))
|
我们可以看到flask的request是从globals.py引入的，而这里的定义request的代码为 request = LocalProxy(partial(_lookup_req_object, 'request')) , 如果有不了解 partial是什么东西的同学需要先补下课，首先需要了解一下 partial 。
不过我们可以简单的理解为 partial(func, 'request') 就是使用 'request' 作为func的第一个默认参数来产生另外一个function。
所以， partial(_lookup_req_object, 'request') 我们可以理解为：
生成一个callable的function，这个function主要是从 _request_ctx_stack 这个LocalStack对象获取堆栈顶部的第一个RequestContext对象，然后返回这个对象的request属性。
这个werkzeug下的LocalProxy引起了我们的注意，让我们来看看它是什么吧：
|
1
2
3
4
5
6
|
@implements_bool
class
LocalProxy(
object
):
"""Acts as a proxy
for
a werkzeug local. Forwards
all
operations to
a proxied
object
. The only operations
not
supported
for
forwarding
are right handed operands
and
any
kind of assignment.
... ...
|
看前几句介绍就能知道它主要是做什么的了，顾名思义，LocalProxy主要是就一个Proxy， 一个为werkzeug的Local对象服务的代理。他把所以作用到自己的操作全部“转发”到 它所代理的对象上去。
那么，这个Proxy通过Python是怎么实现的呢？答案就在源码里：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
# 为了方便说明，我对代码进行了一些删减和改动
@implements_bool
class
LocalProxy(
object
):
__slots__
=
(
'__local'
,
'__dict__'
,
'__name__'
)
def
__init__(
self
, local, name
=
None
):
# 这里有一个点需要注意一下，通过了__setattr__方法，self的
# "_LocalProxy__local" 属性被设置成了local，你可能会好奇
# 这个属性名称为什么这么奇怪，其实这是因为Python不支持真正的
# Private member，具体可以参见官方文档：
# http://docs.python.org/2/tutorial/classes.html#private-variables-and-class-local-references
# 在这里你只要把它当做 self.__local = local 就可以了 :)
object
.__setattr__(
self
,
'_LocalProxy__local'
, local)
object
.__setattr__(
self
,
'__name__'
, name)
def
_get_current_object(
self
):
"""
获取当前被代理的真正对象，一般情况下不会主动调用这个方法，除非你因为
某些性能原因需要获取做这个被代理的真正对象，或者你需要把它用来另外的
地方。
"""
# 这里主要是判断代理的对象是不是一个werkzeug的Local对象，在我们分析request
# 的过程中，不会用到这块逻辑。
if
not
hasattr
(
self
.__local,
'__release_local__'
):
# 从LocalProxy(partial(_lookup_req_object, 'request'))看来
# 通过调用self.__local()方法，我们得到了 partial(_lookup_req_object, 'request')()
# 也就是 ``_request_ctx_stack.top.request``
return
self
.__local()
try
:
return
getattr
(
self
.__local,
self
.__name__)
except
AttributeError:
raise
RuntimeError(
'no object bound to %s'
%
self
.__name__)
# 接下来就是一大段一段的Python的魔法方法了，Local Proxy重载了(几乎)?所有Python
# 内建魔法方法，让所有的关于他自己的operations都指向到了_get_current_object()
# 所返回的对象，也就是真正的被代理对象。
... ...
__setattr__
=
lambda
x, n, v:
setattr
(x._get_current_object(), n, v)
__delattr__
=
lambda
x, n:
delattr
(x._get_current_object(), n)
__str__
=
lambda
x:
str
(x._get_current_object())
__lt__
=
lambda
x, o: x._get_current_object() < o
__le__
=
lambda
x, o: x._get_current_object() <
=
o
__eq__
=
lambda
x, o: x._get_current_object()
=
=
o
__ne__
=
lambda
x, o: x._get_current_object() !
=
o
__gt__
=
lambda
x, o: x._get_current_object() > o
__ge__
=
lambda
x, o: x._get_current_object() >
=
o
... ...
|
事情到了这里，我们在文章开头的第二个疑问就能够得到解答了，我们之所以不需要使用get_request() 这样的方法调用来获取当前的request对象，都是LocalProxy的功劳。
LocalProxy作为一个代理，通过自定义魔法方法。代理了我们对于request的所有操作， 使之指向到真正的request对象。
怎么样，现在知道了 request.args 不是它看上去那么简简单单的吧。
现在，让我们来看看第二个问题，在多线程的环境下，request是怎么正常工作的呢？ 还是让我们回到globals.py吧：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
from
functools
import
partial
from
werkzeug.local
import
LocalStack, LocalProxy
def
_lookup_req_object(name):
top
=
_request_ctx_stack.top
if
top
is
None
:
raise
RuntimeError(
'working outside of request context'
)
return
getattr
(top, name)
# context locals
_request_ctx_stack
=
LocalStack()
request
=
LocalProxy(partial(_lookup_req_object,
'request'
))
|
问题的关键就在于这个 _request_ctx_stack 对象了，让我们找到LocalStack的源码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
class
LocalStack(
object
):
def
__init__(
self
):
# 其实LocalStack主要还是用到了另外一个Local类
# 它的一些关键的方法也被代理到了这个Local类上
# 相对于Local类来说，它多实现了一些和堆栈“Stack”相关方法，比如push、pop之类
# 所以，我们只要直接看Local代码就可以
self
._local
=
Local()
... ...
@property
def
top(
self
):
"""
返回堆栈顶部的对象
"""
try
:
return
self
._local.stack[
-
1
]
except
(AttributeError, IndexError):
return
None
# 所以，当我们调用_request_ctx_stack.top时，其实是调用了 _request_ctx_stack._local.stack[-1]
# 让我们来看看Local类是怎么实现的吧，不过在这之前我们得先看一下下面出现的get_ident方法
# 首先尝试着从greenlet导入getcurrent方法，这是因为如果flask跑在了像gevent这种容器下的时候
# 所以的请求都是以greenlet作为最小单位，而不是thread线程。
try
:
from
greenlet
import
getcurrent as get_ident
except
ImportError:
try
:
from
thread
import
get_ident
except
ImportError:
from
_thread
import
get_ident
# 总之，这个get_ident方法将会返回当前的协程/线程ID，这对于每一个请求都是唯一的
class
Local(
object
):
__slots__
=
(
'__storage__'
,
'__ident_func__'
)
def
__init__(
self
):
object
.__setattr__(
self
,
'__storage__'
, {})
object
.__setattr__(
self
,
'__ident_func__'
, get_ident)
... ...
# 问题的关键就在于Local类重载了__getattr__和__setattr__这两个魔法方法
def
__getattr__(
self
, name):
try
:
# 在这里我们返回调用了self.__ident_func__()，也就是当前的唯一ID
# 来作为__storage__的key
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().some_value 不再是它看上去那么简单了:
# 首先我们先调用get_ident方法来获取当前运行的线程/协程ID
# 然后获取这个ID空间下的some_value属性，就像这样：
#
# Local().some_value -> Local()[current_thread_id()].some_value
#
# 设置属性的时候也是这个道理
|
通过这些分析，相信疑问二也得到了解决，通过使用了当前的线程/协程ID，加上重载一些魔法 方法，Flask实现了让不同工作线程都使用了自己的那一份stack对象。这样保证了request的正常 工作。
说到这里，这篇文章也差不多了。我们可以看到，为了使用者的方便，作为框架和工具的开发者 需要付出很多额外的工作，有时候，使用一些语言上的魔法是无法避免的，Python在这方面也有着 相当不错的支持。
我们所需要做到的就是，学习掌握好Python中那些魔法的部分，使用魔法来让自己的代码更简洁， 使用更方便。
但是要记住，魔法虽然炫，千万不要滥用哦。
479
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
