從原始碼解析Python的Flask框架中request物件的用法
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 # # 設定屬性的時候也是這個道理
通過這些分析,相信疑問二也得到了解決,通過使用了當前的執行緒/協程ID,加上過載一些魔法 方法,Flask實現了讓不同工作執行緒都使用了自己的那一份stack物件。這樣保證了request的正常 工作。
說到這裡,這篇文章也差不多了。我們可以看到,為了使用者的方便,作為框架和工具的開發者 需要付出很多額外的工作,有時候,使用一些語言上的魔法是無法避免的,Python在這方面也有著 相當不錯的支援。