本文发自 http://www.binss.me/blog/the-context-manager-of-python-and-the-applications-in-tornado/,转载请注明出处。
上下文是什么?
在协程中,我将上下文理解为“操作执行时需要的一个特定的执行环境“。在该环境中,“上文”提供该操作需要的变量等信息,“下文“对操作执行返回的结果进行进一步的处理。
比如:
def add(a, b):
op = '+'
result = yield cal(op, a, b)
print('a + b = %d', result)
该协程用于计算a+b的结果。对于具体的操作cal,“上文”提供op、a、b三个变量作为函数调用的参数,“下文“将cal返回的值打印出来。
“上下文管理器”中的“上下文”是否和协程上下文的定义一致呢?
John Jacobsen将定义为如下:
Context managers are a way of allocating and releasing some sort of resource exactly where you need it.
官方的定义如下:
A context manager is an object that defines the runtime context to be established when executing a with statement. The context manager handles the entry into, and the exit from, the desired runtime context for the execution of the block of code.
上下文管理器的典型应用情景有文件访问:需要打开文件(allocating),然后对文件进行操作,最后关闭文件(releasing)。还有线程锁:需要加锁(allocating),然后执行线程安全操作,最后释放锁(releasing)。可见“上下文管理器”中“上下文”和协程中“上下文”的定义一致,都是“操作执行时需要的一个特定的执行环境”。对于文件访问,提供了可以直接读写文件的环境(打开的文件描述符);对于锁应用,提供了无竞争的安全操作环境(有锁,同时只能有一个线程执行临界区代码)。所以上下文管理器,就是该特定的执行环境的提供者。
在Python中,要定义上下文管理器,只需实现上下文管理器协议:实现contextmanager.__enter__()
和contextmanager.__exit__(exc_type, exc_val, exc_tb)
函数,如:
class Context:
def __init__(self, {arguments}):
pass
def __enter__(self):
{setup}
return {value}
def __exit__(self):
{cleanup}
在PEP 343中提供了方便使用上下文管理器的语法糖——with statement:
with Context() as v:
{body}
这段代码在执行时,先是调用Context的构造函数以生成上下文管理对象,然后调用__enter__
函数提供“上文”,并将`__enter__`的返回值赋给as后跟着的变量v以供{body}使用。有了“上文”后,执行{body}。执行完毕后,自动调用__exit__()
执行“下文”操作,然后结束。如果在执行{body}的过程中有异常抛出怎么办?看到__exit__()
的三个参数了吗?它们保存了{body}抛出的异常类型、异常值和异常相关信息,于是我们可以在__exit__()
内对异常进行处理,并通过return True阻止异常向上传播。如果没有异常抛出,那么它们都为None。
除了上述的方法,我们还可以通过@contextlib.contextmanager装饰器来定义上下文管理器。@contextlib.contextmanager可以将生成器(Generator)转换成上下文管理器:
@contextlib.contextmanager
def some_generator({arguments}):
{setup}
try:
yield {value}
finally:
{cleanup}
with some_generator({arguments}) as {variable}:
{body}
等价于上述的:
with Context({arguments}) as {variable}:
{body}
本质上等价于:
{setup}
try:
{variable} = {value}
{body}
finally:
{cleanup}
需要注意的是,yield语句需要使用try...finally语句包起来。因为如果yield语句抛出异常,yield之后的语句将不会执行,这与上下文管理器会调用__exit__()
执行“下文”操作不一致。
至此我们可以发现上下文管理器的优点:封装上下文环境,便于复用;使用简单,with后即进入上下文环境。
Tornado中的stack_context
Tornado的stack_context是对Python上下文管理器的巧妙应用。
在Tornado中,如果通过add_callback等在ioloop的添加了异步回调函数,当回调函数抛出异常时,无法通过在调用add_callback处捕捉到该异常,如:
def callback():
raise Exception('in callback')
def func():
ioloop.add_callback(callback)
ioloop = tornado.ioloop.IOLoop.instance()
try:
func()
except:
print('catch the Exception')
ioloop.start()
虽然是func导致了callback的调用,进而导致异常的抛出。但实际上callback在func中被add_callback后并没有立即执行,只是被放到IOLoop中,等到适当的时机执行。当callback执行时,它的环境早已不是“调用时“(func)的环境,因此对func的try...except无法捕捉到异常,自然“catch the Exception”也就不会被打印。这样的结果显然与我们过去写同步代码的经验不符,我们希望找到一个方法,使得“调用时”和“执行时“能够保持相同的环境。
为了解决这个问题,最直观的办法是对func和callback都使用wrap进行包装,这样就保证callback在“调用时”和“执行时“的环境相同,即都处于
try:
...
except:
print('catch the Exception'):
的包裹之下:
def wrap(callback):
def wrapper(*args, **kwargs):
try:
callback()
except:
print('catch the Exception')
return wrapper
def callback():
raise Exception('in callback')
def func():
ioloop.add_callback(wrap(callback))
ioloop = tornado.ioloop.IOLoop.instance()
wrap(func)()
ioloop.start()
查看ioloop.py的add_callback函数,可以发现Tornado就是使用了这种方案:
......
self._callbacks.append(functools.partial(stack_context.wrap(callback), *args, **kwargs))
看看Tornado怎么做
Tornado通过一个名为StackContext的对象实现对“调用时”上下文环境的保存。
StackContext的定义如下:
class StackContext(object):
def __init__(self, context_factory):
self.context_factory = context_factory
self.contexts = []
self.active = True
def _deactivate(self):
self.active = False
def enter(self):
context = self.context_factory()
self.contexts.append(context)
# 真正进入上下文
context.`__enter__()`
def exit(self, type, value, traceback):
context = self.contexts.pop()
# 真正退出上下文
context.__exit__(type, value, traceback)
def __enter__(self):
self.old_contexts = _state.contexts
# 当前状态入栈
self.new_contexts = (self.old_contexts[0] + (self,), self)
_state.contexts = self.new_contexts
try:
self.enter()
except:
_state.contexts = self.old_contexts
raise
return self._deactivate
def __exit__(self, type, value, traceback):
try:
self.exit(type, value, traceback)
finally:
final_contexts = _state.contexts
# 当前状态出栈
_state.contexts = self.old_contexts
if final_contexts is not self.new_contexts:
raise StackContextInconsistentError(
'stack_context inconsistency (may be caused by yield '
'within a "with StackContext" block)')
self.new_contexts = None
StackContext实现了对上下文管理器的包装,构造函数接受一个参数context_factory,这是一个上下文管理器的工厂方法。调用context_factory可以获得上下文管理器,然后即可通过__enter__()
和__exit__()
进入和退出保存的上下文环境。StackContext也实现了上下文管理器协议,目的是为了和上下文管理器的行为保持一致。
为什么要多此一举,对原有的上下文环境进行包装呢?如果只需维护一个上下文环境,确实不必如此,wrap函数直接通过__enter__()
即可进入保存的“调用时“上下文环境。但是当“调用时”有多个嵌套的上下文环境时(比如A嵌套B,B又嵌套了C),问题来了:如何保证wrap函数能够按顺序调用相应的__enter__()
来进入“调用时“上下文环境呢?StackContext解决的正是这个问题。
先看线程局部变量_state,它的成员contexts是一个二元tuple:
class _State(threading.local):
def __init__(self):
self.contexts = (tuple(), None)
_state = _State()
在StackContext的__enter__()
中,StackContext将自身加入到该contexts[0]的尾端,并将contexts[1]设置为自身。如果把_state理解为上下文嵌套中的一个状态,那么contexts[0]为当前状态下的StackContext栈,保存了从最外层上下文到当前上下文的所有StackContext;而contexts[1]由于保存的是最后一个StackContext,可以认为是栈顶指针。因此如果想进入到“调用时“的上下文环境,只需将“调用时“的_state取出,然后对contexts[0]从头到尾调用enter()即可。更为巧妙的是,为了能够建立状态之间的联系,每一个StackContext在保存当前状态self.new_contexts的同时,也保存了上一个状态self.old_contexts。
画图可以方便理解。以A嵌套B,B又嵌套了C这种环境为例:
在调用do_something时,状态为State C,即((A, B, C), C)。wrap()将State C保存下来,然后在“执行时“调用A、B、C的enter()即可使do_something获得和“调用时”一样的State C上下文。我们来看看wrap具体是怎么做的:
def wrap(fn):
# 如果已经包装过,直接返回
if fn is None or hasattr(fn, '_wrapped'):
return fn
# 保存包装时的上下文状态
# 在闭包中,无法修改外部作用域的局部变量,将外部作为左值将会被认为是闭包内部的局部变量
# 因此为了在闭包(wrapped)内部对_state.contexts进行修改,将其放入list中,这样即使list不能被修改,但list内的元素可以被修改
cap_contexts = [_state.contexts]
# 如果包装时的上下文管理器栈为空(没有上下文),则执行时无需进入上下文,这里进行空包装即可
if not cap_contexts[0][0] and not cap_contexts[0][1]:
# 调用时,取出包装时的上下文管理器容器,然后调用函数,调用完后恢复执行时的上下文管理器容器
def null_wrapper(*args, **kwargs):
try:
current_state = _state.contexts
_state.contexts = cap_contexts[0]
return fn(*args, **kwargs)
finally:
_state.contexts = current_state
# 设置包装标志,防止重复包装
null_wrapper._wrapped = True
return null_wrapper
# 如果上下文管理器栈不为空,需要进入“调用时”的上下文
def wrapped(*args, **kwargs):
ret = None
# 取出包装时的所有上下文管理器,移除那些已经设置为失效的StackContext,然后从头到尾对StackContext调用enter以恢复包装时的上下文
try:
# 保存执行时的上下文状态,用于最后恢复
current_state = _state.contexts
# 移除调用过_deactivate的StackContext
cap_contexts[0] = contexts = _remove_deactivated(cap_contexts[0])
# 设置为调用时的上下文状态
_state.contexts = contexts
exc = (None, None, None)
top = None
last_ctx = 0
stack = contexts[0]
# 对调用时的上下文管理器栈,从头到尾调用enter来设置上下文
for n in stack:
try:
n.enter()
last_ctx += 1
except:
# 如果在设置上下文期间抛出异常,设置top为上一个管理器,因为当前管理器没有成功进入
exc = sys.exc_info()
top = n.old_contexts[1]
# 如果设置上下文都没抛出异常,调用该函数(此时执行时上下文已和调用时的一致)
if top is None:
try:
ret = fn(*args, **kwargs)
except:
exc = sys.exc_info()
# 如果在执行函数期间抛出异常,设置top为当前上下文管理器(栈顶),因为当前管理器已成功进入
top = contexts[1]
# 处理异常,top为应该处理异常的上下文管理器
if top is not None:
exc = _handle_exception(top, exc)
else:
# 如果没异常,反向调用exit以退出之前进入的上下文
while last_ctx > 0:
last_ctx -= 1
c = stack[last_ctx]
try:
c.exit(*exc)
except:
# 如果在退出下文期间抛出异常,设置top为上一个管理器,因为当前管理器已经退出过了
exc = sys.exc_info()
top = c.old_contexts[1]
break
else:
top = None
# 处理异常
if top is not None:
exc = _handle_exception(top, exc)
# 如果异常还是没被处理,只能抛出
if exc != (None, None, None):
raise_exc_info(exc)
finally:
# 恢复执行时的上下文状态
_state.contexts = current_state
return ret
# 设置包装标志,防止重复包装
wrapped._wrapped = True
return wrapped
可以看到,wrap在调用时生成函数闭包,把“调用时”的上下文状态_state.contexts保存起来,然后在“执行时”将上下文状态取出,从头到尾对StackContext栈中的StackContext调用enter()从而使其管理的上下文管理器的__enter__()
得到调用,设置相应的上下文。如果没有异常抛出,此时“执行时”上下文已和“调用时”的一致,可以放心地调用函数。如果调用成功,从尾到头对StackContext栈中的StackContext调用exit()从而使其管理的上下文管理器的__exit__()
得到调用,退出相应的上下文。注意如果在enter或exit的过程中有异常抛出,那么当前状态的上一个状态栈顶一个StackContext将作为异常的第一处理者对异常进行处理。而如果在函数调用的过程中有异常抛出,那么当前状态的栈顶StackContext将作为异常的第一处理者对异常进行处理。处理异常的过程可以看成是一个冒泡的过程:
def _handle_exception(tail, exc):
while tail is not None:
try:
if tail.exit(*exc):
exc = (None, None, None)
except:
exc = sys.exc_info()
tail = tail.old_contexts[1]
return exc
从第一处理者(处理异常的最内层)开始,调用exit,希望能够处理掉该异常。如果异常没有被处理,那么通过old_contexts[1]获得上一层的StackContext让其处理,直到到达最外层的StackContext为止。该冒泡过程符合我们以往对于异常传播的经验:
另外一个设计巧妙的地方在于用户可以通过调用_deactivate()将StackContext设置为失效,这样在进入上下文的过程中将忽略此层的上下文。如何让用户调用_deactivate()呢?这里再次利用到了with语法糖的特性,只需在上下文管理器的__enter__()
中返回该函数,即可通过as的形式赋给外部变量,并在with statement中使用:
with StackContext() as deactivate:
deactivate()
最后,我们尝试使用Tornado的stack_context来处理异步回调中抛出异常的问题:
def callback():
print('Run callback')
raise Exception('in callback')
@contextlib.contextmanager
def A():
print("Enter A context")
try:
yield
except Exception as e:
print("A catch the exception: %s" % e)
print("Exit A context")
@contextlib.contextmanager
def B():
print("Enter B context")
try:
yield
except Exception as e:
print("B catch the exception: %s" % e)
print("Exit B context")
@contextlib.contextmanager
def C():
print("Enter C context")
try:
yield
except Exception as e:
print("C catch the exception: %s" % e)
print("Exit C context")
ioloop = tornado.ioloop.IOLoop.instance()
with StackContext(A):
with StackContext(B):
with StackContext(C):
ioloop.add_callback(callback)
ioloop.start()
输出如下:
Enter A context
Enter B context
Enter C context
Exit C context
Exit B context
Exit A context
Enter A context
Enter B context
Enter C context
Run callback
C catch the exception: in callback
Exit C context
B catch the exception: in callback
Exit B context
A catch the exception: in callback
Exit A context
ERROR:tornado.application:Exception in callback functools.partial(.wrapped at 0x7fbb52740048>)
Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/tornado/ioloop.py", line 600, in _run_callback
ret = callback()
File "/usr/local/lib/python3.5/dist-packages/tornado/stack_context.py", line 343, in wrapped
raise_exc_info(exc)
File "", line 3, in raise_exc_info
File "/usr/local/lib/python3.5/dist-packages/tornado/stack_context.py", line 314, in wrapped
ret = fn(*args, **kwargs)
File "ttt.py", line 21, in callback
raise Exception('in callback')
Exception: in callback
前六行输出于“调用时”,在with的嵌套下我们调用了上下文管理器A、B、C的__enter__()
,在ioloop中添加回调函数callback后调用A、B、C的__exit__()
退出。到了“执行时”,6-9行为callback设置上下文环境,然后调用callback函数。callback抛出了异常,第一处理者为C,于是在_handle_exception的冒泡机制下异常从C到B到A,最后到达全局层面。这时问题又来了。不是说可以通过设置上下文管理器__exit__()
的返回值为True来阻止异常继续抛出的吗?阅读源码,发现以下内容:
if tail.exit(*exc):
exc = (None, None, None)
...
def exit(self, type, value, traceback):
context = self.contexts.pop()
context.__exit__(type, value, traceback)
对于StackContext来说,调用exit()是没有返回值的,于是exc内的元素永远不会设置为None,设置__exit__()
的返回值并没有什么卵用。如果改为这样就可以满足我们的期望:
def exit(self, type, value, traceback):
context = self.contexts.pop()
return context.__exit__(type, value, traceback)
正准备Push之际,查看了stack_context_test的相关测试用例,并没有使用StackContext来处理异常的用例。对待异常,其使用了ExceptionStackContext来处理,在ExceptionStackContext的exit()中,将exception_handler的返回值设置为True可以阻止异常的继续抛出:
def exit(self, type, value, traceback):
if type is not None:
return self.exception_handler(type, value, traceback)
所以估计StackContext并非是用来传递异常的,而是用来传递相关环境的。想至此,默默地取消了Push。
总结
Python中的上下文管理器和with语法糖极大地方便了我们的编程,在封装了上下文管理器后,我们只需专注于写with statement即可。Tornado的stack_context对上下文管理器的应用更是巧妙到了极致,其通过定义栈式上下文管理器,实现了上下文嵌套环境下的上下文设置与恢复。
参考
https://en.wikibooks.org/wiki/Python_Programming/Context_Managers
1F ponn 8 years, 1 month ago 回复
分析的十分不错,学习了。