从源码解析Python的Flask框架中request对象的用法_Python

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属性，而不用使用比如：

				?

									from flask import get_request

									# 获取当前request

									request = get_request()

									get_request().args

这样的方式呢？flask是怎么把request对应到当前的请求对象的呢？

疑问二 : 在真正的生产环境中，同一个工作进程下面可能有很多个线程（又或者是协程），就像我刚刚所说的，request这个类实例是怎么在这样的环境下正常工作的呢？

要知道其中的秘密，我们只能从flask的源码开始看了。

源码，源码，还是源码
首先我们打开flask的源码，从最开始的__init__.py来看看request是怎么出来的：

				?

									# 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引起了我们的注意，让我们来看看它是什么吧：

				?

									@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是怎么实现的呢？答案就在源码里：

				?

									# 为了方便说明，我对代码进行了一些删减和改动

									@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吧：

				?

									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的源码：

				?

									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

									  #

									  # 设置属性的时候也是这个道理