通常来说,实现上下文管理器,需要编写一个带有__enter__和 __exit__的类,类似这样:

class ListTransaction:

    def __init__(self, orig_list):
self.orig_list = orig_list
self.working = list(orig_list) def __enter__(self):
return self.working def __exit__(self, exc_type, exc_val, exc_tb):
self.orig_list[:] = self.working

然而,在contextlib模块中,还提供了@contextmanager装饰器,将一个生成器函数当成上下文管理器使用,上面的代码在大部分,是与下面的代码等效的。

本文的list_transaction函数的代码来自:《Python Cookbook》 9.22 以简单的方式定义上下文管理器

from contextlib import contextmanager
@contextmanager
def list_transaction(orig_list):
working = list(orig_list)
yield working
orig_list[:] = working

先逐一分析上面的代码:

  1. 因为list是可变类型,所以通过list(orig_list),对值进行复制,创建一个新的list,即working。
  2. 以yield为分隔,在yield之前的代码,包括yield working,会在contextmanager装饰器的__enter__方法中被调用
  3. 代码在执行到yield时暂停,同时yield working,会将working产出。yield产出的值,作为__enter__的返回值,赋值给as之后的变量
  4. 当with块的代码执行完成后, 上下文管理器会在yield处恢复,继续执行yield之后的代码。
  5. yield 之后的代码,则在contextmanager装饰器中的__exit__方法中被调用

测试代码如下:

当执行过程中,没有引发异常时,执行正常,输出 [1, 2, 3, 4, 5]

    items_1 = [1, 2, 3]
with list_transaction(items_1) as working_1:
working_1.append(4)
working_1.append(5)
print(items_1)

当执行过程中,引发异常时,yield后的代码不会执行,orig_list不会被修改。从而实现事务的效果,orig_list仍是 [1, 2, 3]

    items_2 = [1, 2, 3]
try:
with list_transaction(items_2) as working_2:
working_2.append(4)
working_2.append(5)
raise RuntimeError('oops')
except Exception as ex:
print(ex)
finally:
print(items_2)

上下文管理器类与@contextmanager中最大的区别在于对异常的处理。

分析contextmanager的源码可知,@contextmanager装饰器的本质是实例化一个_GeneratorContextManager对象。

def contextmanager(func):
@wraps(func)
def helper(*args, **kwds):
return _GeneratorContextManager(func, args, kwds)
return helper

进一步查看_GeneratorContextManager源码,可知_GeneratorContextManager实现的是一个上下文管理器对象

class _GeneratorContextManager(ContextDecorator):
"""Helper for @contextmanager decorator.""" def __init__(self, func, args, kwds):
self.gen = func(*args, **kwds)
self.func, self.args, self.kwds = func, args, kwds
# Issue 19330: ensure context manager instances have good docstrings
doc = getattr(func, "__doc__", None)
if doc is None:
doc = type(self).__doc__
self.__doc__ = doc
# Unfortunately, this still doesn't provide good help output when
# inspecting the created context manager instances, since pydoc
# currently bypasses the instance docstring and shows the docstring
# for the class instead.
# See http://bugs.python.org/issue19404 for more details. def _recreate_cm(self):
# _GCM instances are one-shot context managers, so the
# CM must be recreated each time a decorated function is
# called
return self.__class__(self.func, self.args, self.kwds) def __enter__(self):
try:
return next(self.gen)
except StopIteration:
raise RuntimeError("generator didn't yield") from None def __exit__(self, type, value, traceback):
if type is None:
try:
next(self.gen)
except StopIteration:
return
else:
raise RuntimeError("generator didn't stop")
else:
if value is None:
# Need to force instantiation so we can reliably
# tell if we get the same exception back
value = type()
try:
self.gen.throw(type, value, traceback)
raise RuntimeError("generator didn't stop after throw()")
except StopIteration as exc:
# Suppress StopIteration *unless* it's the same exception that
# was passed to throw(). This prevents a StopIteration
# raised inside the "with" statement from being suppressed.
return exc is not value
except RuntimeError as exc:
# Likewise, avoid suppressing if a StopIteration exception
# was passed to throw() and later wrapped into a RuntimeError
# (see PEP 479).
if exc.__cause__ is value:
return False
raise
except:
# only re-raise if it's *not* the exception that was
# passed to throw(), because __exit__() must not raise
# an exception unless __exit__() itself failed. But throw()
# has to raise the exception to signal propagation, so this
# fixes the impedance mismatch between the throw() protocol
# and the __exit__() protocol.
#
if sys.exc_info()[1] is not value:
raise

简要分析实现的代码:

__enter__方法:

  1. self.gen = func(*args, **kwds) 获取生成器函数返回的生成器,并赋值给self.gen
  2. with代码块进入__enter__方法时,调用生成器的__next__方法,使代码执行到yield处暂停
  3. 将yield产出的值作为__enter__的返回值
  4. 因为__enter__方法只会执行一次,如果第一次调用生成器的__next__方法,就抛出StopIteration异常,说明生成器存在问题,则抛出RuntimeError

__exit__方法:

正常执行的情况:

  1. def __exit__(self, type, value, traceback)接收三个参数,第一个参数是异常类,第二个参数是异常对象,第三个参数是trackback对象
  2. 如果with内的代码执行正常,没有抛出异常,则上述三个参数都为None
  3. __exit__代码中首先对type是否None进行判断,如果type为None,说明with代码内部执行正常,所以调用生成器的__next__方法。此时生成器在yield处恢复运行,继续执行yield之后的代码
  4. 正常情况下,调用__next__方法,迭代应结束,抛出StopIteration异常;如果没有抛出StopIteration异常,说明生成器存在问题,则抛出RuntimeError

出现异常的情况:

  1. 如果type类型不为None,说明在with代码内部执行时出现异常。如果异常对象value为None,则强制使用异常类实例化一个新的异常对象,并赋值给value
  2. 使用throw方法,将异常对象value传递给生成器函数,此时生成器在yield处恢复执行,并接收到异常信息
  3. 通常情况下,yield语句应该在try except代码块中执行,用于捕获__exit__方法传递给生成器的异常信息,并进行处理
  4. 如果生成器函数可以处理异常,迭代完成后,自动抛出StopIteration。
  5. __exit__ 捕获并压制StopIteration,除非with内的代码也抛出了StopIteration。return exc is not value,exc是捕获到的StopIteration异常实例,value是with内代码执行时抛出的异常。在__exit__方法中,return True告诉解释器异常已经处理,除此以外,所有的异常都会向上冒泡。
  6. 如果生成器没有抛出StopIteration异常,说明迭代没有正常结束,则__exit__方法抛出RuntimeError,同样的,除非with代码块内部也抛出RuntimeError,否则RuntimeError会在__exit__中被捕获并且压制。

所以,以类的方式实现的上下文管理器,在引发异常时,__exit__方法内的代码仍会正常执行;

而以生成器函数实现的上下文管理器,在引发异常时,__exit__方法会将异常传递给生成器,如果生成器无法正确处理异常,则yield之后的代码不会执行。

所以,大部分情况下,yield都必须在try...except中,除非设计之初就是让yield之后的代码在with代码块内部出现异常时不执行。

测试代码:

以类的方式实现上下文管理器,当没有引发异常时, # 其执行结果与@contextmanager装饰器装饰器的上下文管理器函数相同,输出 [1, 2, 3, 4, 5]

    items_3 = [1, 2, 3]
with ListTransaction(items_3) as working_3:
working_3.append(4)
working_3.append(5)
print(items_3)

当执行代码过程中引发异常时,即使没有对异常进行任何处理,__exit__方法也会正常执行,对self.orig_list进行修改(python是引用传值,而list是可变类型,对orig_list的任何引用的修改,都会改变orig_list的值),所以输出结果与没有引发异常时相同:[1, 2, 3, 4, 5]

    items_4 = [1, 2, 3]
try:
with ListTransaction(items_4) as working_4:
working_4.append(4)
working_4.append(5)
raise RuntimeError('oops')
except Exception as ex:
print(ex)
finally:
print(items_4)

完整代码:https://github.com/blackmatrix7/python-learning/blob/master/class_/contextlib_.py

使用@contextmanager装饰器实现上下文管理器的更多相关文章

  1. python 上下文管理器contextlib.ContextManager

    1 模块简介 在数年前,Python 2.5 加入了一个非常特殊的关键字,就是with.with语句允许开发者创建上下文管理器.什么是上下文管理器?上下文管理器就是允许你可以自动地开始和结束一些事情. ...

  2. Python上下文管理器

    在Python中让自己创建的函数.类.对象支持with语句,就实现了上线文管理协议.我们经常使用with open(file, "a+") as f:这样的语句,无需手动调用f.c ...

  3. with与上下文管理器

    如果你有阅读源码的习惯,可能会看到一些优秀的代码经常出现带有 "with" 关键字的语句,它通常用在什么场景呢? 对于系统资源如文件.数据库连接.socket 而言,应用程序打开这 ...

  4. (转)Python中的上下文管理器和Tornado对其的巧妙应用

    原文:https://www.binss.me/blog/the-context-manager-of-python-and-the-applications-in-tornado/ 上下文是什么? ...

  5. (转)contextlib — 上下文管理器工具

    原文:https://pythoncaff.com/docs/pymotw/contextlib-context-manager-tool/95 这是一篇社区协同翻译的文章,你可以点击右边区块信息里的 ...

  6. 如何正确理解关键字"with"与上下文管理器

    转自:https://foofish.net/with-and-context-manager.html 如果你有阅读源码的习惯,可能会看到一些优秀的代码经常出现带有 “with” 关键字的语句,它通 ...

  7. contextlib:上下文管理器工具

    介绍 contextlib模块包含的工具可以用于处理上下文管理器和with语句 上下文管理器API ''' 上下文管理器(context manager)负责管理一个代码块中的资源,会在进入代码块时创 ...

  8. Python上下文管理器你学会了吗?

    ​什么是上下文管理器 对于像文件操作.连接数据库等资源管理的操作,我们必须在使用完之后进行释放,不然就容易造成资源泄露.为了解决这个问题,Python的解决方式便是上下文管理器.上下文管理器能够帮助你 ...

  9. Python 的上下文管理器是怎么设计的?

    花下猫语:最近,我在看 Python 3.10 版本的更新内容时,发现有一个关于上下文管理器的小更新,然后,突然发现上下文管理器的设计 PEP 竟然还没人翻译过!于是,我断断续续花了两周时间,终于把这 ...

随机推荐

  1. LNMP1.3 一键配置环境,简单方便

    系统需求: CentOS/RHEL/Fedora/Debian/Ubuntu/Raspbian Linux系统 需要3GB以上硬盘剩余空间 需要128MB以上内存(如果为128MB的小内存VPS,Xe ...

  2. Web前端学习——JavaScript

    一.JavaScript介绍JavaScript一种直译式脚本语言,是一种动态类型.弱类型.基于原型的语言,内置支持类型.它的解释器被称为JavaScript引擎,为浏览器的一部分,广泛用于客户端的脚 ...

  3. 【前端】Util.js-ES6实现的常用100多个javaScript简短函数封装合集(持续更新中)

    Util.js (持续更新中...) 项目地址: https://github.com/dragonir/Util.js 项目描述 Util.js 是对常用函数的封装,方便在实际项目中使用,主要内容包 ...

  4. 机房收费系统——转换list泛型时,字段名称不正确应出现故障

    因为之前对泛型研究了一番,所以就開始尝试着在机房收费系统重构中增加了泛型的使用. 可是到了做学生查看剩余金额这个功能的时候,还是依照之前的方法做的,可是在载入数据的时候班级这个框就没有显示出来--然后 ...

  5. Ambari源代码分析之Resource.Type与ResourceProvider相应关系

    前面提到.每一种Resource都相应一个ResourceProvider,以下给出其相应关系: Resource.Type ResourceProvider Workflow WorkflowRes ...

  6. python文件和文件夹訪问File and Directory Access

    http://blog.csdn.net/pipisorry/article/details/47907589 os.path - Common pathname manipulations 都是和路 ...

  7. POJ - 1611The Suspects-并查集

    POJ - 1611 The Suspects Time Limit: 1000MS   Memory Limit: 20000KB   64bit IO Format: %I64d & %I ...

  8. 浅谈MySQL中的查询优化

    mysql的性能优化包罗甚广: 索引优化,查询优化,查询缓存,服务器设置优化,操作系统和硬件优化,应用层面优化(web服务器,缓存)等等.这里的记录的优化技巧更适用于开发人员,都是从网络上收集和自己整 ...

  9. java注解(转并做修改)

    本文由 ImportNew - 人晓 翻译自 idlebrains.欢迎加入翻译小组.转载请见文末要求. 自Java5.0版本引入注解之后,它就成为了Java平台中非常重要的一部分.开发过程中,我们也 ...

  10. 「mysql优化专题」90%程序员没听过的存储过程和存储函数教学(7)

    一.MYSQL储存过程简介(技术文): 储存过程是一个可编程的函数,它在数据库中创建并保存.它可以有SQL语句和一些特殊的控制结构组成.当希望在不同的应用程序或平台上执行相同的函数,或者封装特定功能时 ...