Python中把进入代码块前调用__enter__ 方法并在离开代码块后调用__exit__方法的对象作为上下文管理器,本文中我们就来深入解析Python中的上下文管理器,来看看上下文管理器的作用及用法:
1. 上下文管理器是什么?
举个例子,你在写Python代码的时候经常将一系列操作放在一个语句块中:
(1)当某条件为真 – 执行这个语句块
(2)当某条件为真 – 循环执行这个语句块
有时候我们需要在当程序在语句块中运行时保持某种状态,并且在离开语句块后结束这种状态。
所以,事实上上下文管理器的任务是 – 代码块执行前准备,代码块执行后收拾。
上下文管理器是在Python2.5加入的功能,它能够让你的代码可读性更强并且错误更少。接下来,让我们来看看该如何使用。
2. 如何使用上下文管理器?
看代码是最好的学习方式,来看看我们通常是如何打开一个文件并写入”Hello World”?
# coding=utf-8
filename = 'my_file.txt'
mode = 'w' # Mode that allows to write to the file
writer = open(filename, mode)
writer.write('Hello ')
writer.write('World')
writer.close()
1-2行,我们指明文件名以及打开方式(写入)。
第3行,打开文件,4-5行写入“Hello world”,第6行关闭文件。
这样不就行了,为什么还需要上下文管理器?但是我们忽略了一个很小但是很重要的细节:如果我们没有机会到达第6行关闭文件,那会怎样?
举个例子,磁盘已满,因此我们在第4行尝试写入文件时就会抛出异常,而第6行则根本没有机会执行。
当然,我们可以使用try-finally语句块来进行包装:
writer = open(filename, mode)
try:
writer.write('Hello ')
writer.write('World')
finally:
writer.close()
finally语句块中的代码无论try语句块中发生了什么都会执行。因此可以保证文件一定会关闭。这么做有什么问题么?当然没有,但当我们进行一些比写入“Hello world”更复杂的事情时,try-finally语句就会变得丑陋无比。例如我们要打开两个文件,一个读一个写,两个文件之间进行拷贝操作,那么通过with语句能够保证两者能够同时被关闭。
OK,让我们把事情分解一下:
(1)首先,创建一个名为“writer”的文件变量。
(2)然后,对writer执行一些操作。
(3)最后,关闭writer。
这样是不是优雅多了?
with open(filename, mode) as writer:
writer.write('Hello ')
writer.write('World')
让我们深入一点,“with”是一个新关键词,并且总是伴随着上下文管理器出现。“open(filename, mode)”曾经在之前的代码中出现。“as”是另一个关键词,它指代了从“open”函数obj.__enter__()返回的内容,不一定是“open”函数obj,并且把它赋值给了一个新的变量。“writer”是一个新的变量名。
2-3行,缩进开启一个新的代码块。在这个代码块中,我们能够对writer做任意操作。这样我们就使用了“open”上下文管理器,它保证我们的代码既优雅又安全。它出色的完成了try-finally的任务。
open函数既能够当做一个简单的函数使用,又能够作为上下文管理器。这是因为open函数返回了一个文件类型(file type)变量,它支持上下文管理协议(__enter__()和__exit__()方法)。而这个文件类型实现了我们之前用到的write方法,但是想要作为上下文管理器还必须实现一些特殊的方法,我会在接下来的小节中介绍。
3. 自定义上下文管理器
让我们来写一个“open”上下文管理器。
要实现上下文管理器,必须实现两个方法 – 一个负责进入语句块的准备操作,另一个负责离开语句块的善后操作。同时,我们需要两个参数:文件名和打开方式。
Python类包含两个特殊的方法,分别名为:__enter__以及__exit__(双下划线作为前缀及后缀)。
当一个对象被用作上下文管理器时:
(1)__enter__ 方法将在进入代码块前被调用。
(2)__exit__ 方法则在离开代码块之后被调用(即使在代码块中遇到了异常)。
下面是上下文管理器的一个例子,它分别进入和离开代码块时进行打印。
class PypixContextManagerDemo:
def __enter__(self):
print('Entering the block')
return ('from __enter__()')
def __exit__(self, *unused):
print ('Exiting the block')
with PypixContextManagerDemo() as a:
print ('In the block',a)
'''
Entering the block
In the block from __enter__()
Exiting the block
'''
4.如何处理异常
我们完全忽视了语句块内部可能出现的问题。
如果语句块内部发生了异常,__exit__方法将被调用,而异常将会被重新抛出(re-raised)。当处理文件写入操作时,大部分时间你肯定不希望隐藏这些异常,所以这是可以的。而对于不希望重新抛出的异常,我们可以让__exit__方法简单的返回True来忽略语句块中发生的所有异常(大部分情况下这都不是明智之举)。
捕获异常:
当一个异常在with块中抛出时,它作为参数传递给__exit__。三个参数被使用,和sys.exc_info()返回的相同:类型type、值value和回溯(traceback)。当没有异常抛出时,三个参数都是None。上下文管理器可以通过从__exit__返回一个真(True)值来“吞下”异常。例外可以轻易忽略,因为如果__exit__不使用return直接结束,返回None——一个假(False)值,之后在__exit__结束后会重新抛出异常,并被传递出上下文。
捕获异常的能力创造了有意思的可能性。一个来自单元测试的经典例子——我们想确保一些代码抛出正确种类的异常:
class assert_raises(object):
# based on pytest and unittest.TestCase
def __init__(self, type):
self.type = type
def __enter__(self):
pass
def __exit__(self, type, value, traceback):
if type is None:
raise AssertionError('exception expected')
if issubclass(type, self.type):
return True # swallow the expected exception
raise AssertionError('wrong exception type')
with assert_raises(KeyError):
{}['foo']
上例从空字典中取key 'foo',抛出KeyError.在__exit__()被吞掉。如果代码中无异常或者非KeyError异常,__exit__()会抛出异常。确保代码中出现KeyError的异常!
5. 谈一些关于上下文库(contextlib)的内容
contextlib是一个Python模块,作用是提供更易用的上下文管理器。
(1)contextlib.closing
假设我们有一个创建数据库函数,它将返回一个数据库对象,并且在使用完之后关闭相关资源(数据库连接会话等)
我们可以像以往那样处理或是通过上下文管理器:
1 2 |
|
contextlib.closing方法将在语句块结束后调用数据库的关闭方法。
(2)contextlib.nested
另一个很cool的特性能够有效地帮助我们减少嵌套:
假设我们有两个文件,一个读一个写,需要进行拷贝。
以下是不提倡的:
1 2 3 |
|
可以通过contextlib.nested进行简化:
1 2 3 |
|
在Python2.7中这种写法被一种新语法取代:
1 2 3 4 |
|
contextlib模块支持通过包装生成器函数,更加容易地实现自定义上下文管理器。对于Python高级玩家来说,任何能够被yield关键词分割成两部分的函数,都能够通过装饰器装饰的上下文管理器来实现。任何在yield之前的内容都可以看做在代码块执行前__enter__()的操作,而任何yield之后的操作对应__exit__()中的操作。传递给yield的值用作__enter__()的返回值!!!
这里我举一个线程锁的例子:
锁机制保证两段代码在同时执行时不会互相干扰。例如我们有两块并行执行的代码同时写一个文件,那我们将得到一个混合两份输入的错误文件。但如果我们能有一个锁,任何想要写文件的代码都必须首先获得这个锁,那么事情就好办了。如果你想了解更多关于并发编程的内容,请参阅相关文献。
下面是线程安全写函数的例子:
1 2 3 4 5 6 7 8 |
|
接下来,让我们用上下文管理器来实现,回想之前关于yield和contextlib的分析:
# coding=utf-8
import threading
lock = threading.Lock()
import contextlib
@contextlib.contextmanager
def PypixContextManagerDemo():
# def __enter__(self):
lock.acquire()
print('Entering the block')
# return ('from __enter__()')
yield 'from __enter__()'
# def __exit__(self, *unused):
print ('Exiting the block')
lock.release()
with PypixContextManagerDemo() as a:
print ('In the block',a)
'''
Entering the block
In the block from __enter__()
Exiting the block
'''
从上例可以看出,用@contextlib.contextmanager包装PypixContextManagerDemo()生成器函数和自定义上下文管理器类PypixContextManagerDemo结果一样,且结构更紧凑!!!
特别注意,这不是异常安全(exception safe)的写法。如果你想保证异常安全,请对yield使用try语句。幸运的是threading。lock已经是一个上下文管理器了,所以我们只需要简单地:
1 2 3 4 5 6 |
|
因为threading.lock在异常发生时会通过__exit__函数返回False,这将在yield被调用是被重新抛出。这种情况下锁将被释放,但对于“print ‘Releasing'”的调用则不会被执行,除非我们重写try-finally。
如果你希望在上下文管理器中使用“as”关键字,那么就用yield返回你需要的值,它将通过as关键字赋值给新的变量。下面我们就仔细来讲一下。
6.使用生成器定义上下文管理器
当讨论生成器时,据说我们相比实现为类的迭代器更倾向于生成器,因为它们更短小方便,状态被局部保存而非实例和变量中。另一方面,正如双向通信章节描述的那样,生成器和它的调用者之间的数据流可以是双向的。包括异常,可以直接传递给生成器。我们想将上下文管理器实现为特殊的生成器函数。事实上,生成器协议被设计成支持这个用例。
1 2 3 4 5 6 7 |
|
contextlib.contextmanager装饰一个生成器并转换为上下文管理器。生成器必须遵循一些被包装(wrapper)函数强制执行的法则——最重要的是它至少yield一次。yield之前的部分从__enter__执行,上下文管理器中的代码块当生成器停在yield时执行,剩下的在__exit__中执行。如果异常被抛出,解释器通过__exit__的参数将之传递给包装函数,包装函数于是在yield语句处抛出异常。通过使用生成器,上下文管理器变得更短小精炼。
让我们用生成器重写closing的例子:
1 2 3 4 5 6 |
|
这里我们用装饰器将生成函数转化为上下文管理器!