接触Python也有一段时间了，Python相关的框架和模块也接触了不少，希望把自己接触到的自己 觉得比较好的设计和实现分享给大家，于是取了一个“Charming Python”的小标，算是给自己开了一个头吧， 希望大家多多批评指正。 :)
from flask import request
Flask 是一个人气非常高的Python Web框架，笔者也拿它写过一些大大小小的项目，Flask 有一个特性我非常的喜欢，就是无论在什么地方，如果你想要获取当前的request对象，只要 简单的：
from flask import request
# 从当前request获取内容
request.args
request.forms
request.cookies
... ...</div>
非常简单好记，用起来也非常的友好。不过，简单的背后藏的实现可就稍微有一些复杂了。 跟随我的文章来看看其中的奥秘吧！
两个疑问？
在我们往下看之前，我们先提出两个疑问：
疑问一 : request ，看上去只像是一个静态的类实例，我们为什么可以直接使用request.args 这样的表达式来获取当前request的args属性，而不用使用比如：
from flask import get_request
# 获取当前request
request = get_request()
get_request().args</div>
这样的方式呢？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'))</div>
我们可以看到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.
... ...
</div>
看前几句介绍就能知道它主要是做什么的了，顾名思义，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__