从源码解析Python的Flask框架中request对象的用法
fromflaskimportrequest
Flask是一个人气非常高的PythonWeb框架,笔者也拿它写过一些大大小小的项目,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属性,而不用使用比如:
fromflaskimportget_request #获取当前request request=get_request() get_request().args
这样的方式呢?flask是怎么把request对应到当前的请求对象的呢?
疑问二:在真正的生产环境中,同一个工作进程下面可能有很多个线程(又或者是协程),就像我刚刚所说的,request这个类实例是怎么在这样的环境下正常工作的呢?
要知道其中的秘密,我们只能从flask的源码开始看了。
源码,源码,还是源码
首先我们打开flask的源码,从最开始的__init__.py来看看request是怎么出来的:
#File:flask/__init__.py from.globalsimportcurrent_app,g,request,session,_request_ctx_stack #File:flask/globals.py fromfunctoolsimportpartial fromwerkzeug.localimportLocalStack,LocalProxy def_lookup_req_object(name): top=_request_ctx_stack.top iftopisNone: raiseRuntimeError('workingoutsideofrequestcontext') returngetattr(top,name) #contextlocals _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 classLocalProxy(object): """Actsasaproxyforawerkzeuglocal.Forwardsalloperationsto aproxiedobject.Theonlyoperationsnotsupportedforforwarding arerighthandedoperandsandanykindofassignment. ......
看前几句介绍就能知道它主要是做什么的了,顾名思义,LocalProxy主要是就一个Proxy,一个为werkzeug的Local对象服务的代理。他把所以作用到自己的操作全部“转发”到它所代理的对象上去。
那么,这个Proxy通过Python是怎么实现的呢?答案就在源码里:
#为了方便说明,我对代码进行了一些删减和改动 @implements_bool classLocalProxy(object): __slots__=('__local','__dict__','__name__') def__init__(self,local,name=None): #这里有一个点需要注意一下,通过了__setattr__方法,self的 #"_LocalProxy__local"属性被设置成了local,你可能会好奇 #这个属性名称为什么这么奇怪,其实这是因为Python不支持真正的 #Privatemember,具体可以参见官方文档: #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 #的过程中,不会用到这块逻辑。 ifnothasattr(self.__local,'__release_local__'): #从LocalProxy(partial(_lookup_req_object,'request'))看来 #通过调用self.__local()方法,我们得到了partial(_lookup_req_object,'request')() #也就是``_request_ctx_stack.top.request`` returnself.__local() try: returngetattr(self.__local,self.__name__) exceptAttributeError: raiseRuntimeError('noobjectboundto%s'%self.__name__) #接下来就是一大段一段的Python的魔法方法了,LocalProxy重载了(几乎)?所有Python #内建魔法方法,让所有的关于他自己的operations都指向到了_get_current_object() #所返回的对象,也就是真正的被代理对象。 ...... __setattr__=lambdax,n,v:setattr(x._get_current_object(),n,v) __delattr__=lambdax,n:delattr(x._get_current_object(),n) __str__=lambdax:str(x._get_current_object()) __lt__=lambdax,o:x._get_current_object()<o __le__=lambdax,o:x._get_current_object()<=o __eq__=lambdax,o:x._get_current_object()==o __ne__=lambdax,o:x._get_current_object()!=o __gt__=lambdax,o:x._get_current_object()>o __ge__=lambdax,o:x._get_current_object()>=o ......
事情到了这里,我们在文章开头的第二个疑问就能够得到解答了,我们之所以不需要使用get_request()这样的方法调用来获取当前的request对象,都是LocalProxy的功劳。
LocalProxy作为一个代理,通过自定义魔法方法。代理了我们对于request的所有操作,使之指向到真正的request对象。
怎么样,现在知道了request.args不是它看上去那么简简单单的吧。
现在,让我们来看看第二个问题,在多线程的环境下,request是怎么正常工作的呢?还是让我们回到globals.py吧:
fromfunctoolsimportpartial fromwerkzeug.localimportLocalStack,LocalProxy def_lookup_req_object(name): top=_request_ctx_stack.top iftopisNone: raiseRuntimeError('workingoutsideofrequestcontext') returngetattr(top,name) #contextlocals _request_ctx_stack=LocalStack() request=LocalProxy(partial(_lookup_req_object,'request'))
问题的关键就在于这个_request_ctx_stack对象了,让我们找到LocalStack的源码:
classLocalStack(object): def__init__(self): #其实LocalStack主要还是用到了另外一个Local类 #它的一些关键的方法也被代理到了这个Local类上 #相对于Local类来说,它多实现了一些和堆栈“Stack”相关方法,比如push、pop之类 #所以,我们只要直接看Local代码就可以 self._local=Local() ...... @property deftop(self): """ 返回堆栈顶部的对象 """ try: returnself._local.stack[-1] except(AttributeError,IndexError): returnNone #所以,当我们调用_request_ctx_stack.top时,其实是调用了_request_ctx_stack._local.stack[-1] #让我们来看看Local类是怎么实现的吧,不过在这之前我们得先看一下下面出现的get_ident方法 #首先尝试着从greenlet导入getcurrent方法,这是因为如果flask跑在了像gevent这种容器下的时候 #所以的请求都是以greenlet作为最小单位,而不是thread线程。 try: fromgreenletimportgetcurrentasget_ident exceptImportError: try: fromthreadimportget_ident exceptImportError: from_threadimportget_ident #总之,这个get_ident方法将会返回当前的协程/线程ID,这对于每一个请求都是唯一的 classLocal(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 returnself.__storage__[self.__ident_func__()][name] exceptKeyError: raiseAttributeError(name) def__setattr__(self,name,value): ident=self.__ident_func__() storage=self.__storage__ try: storage[ident][name]=value exceptKeyError: 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中那些魔法的部分,使用魔法来让自己的代码更简洁,使用更方便。
但是要记住,魔法虽然炫,千万不要滥用哦。