AdvancedPython（1）——装饰器(Decorator)

装饰器&＃xff0c;作为Python中的一个非常重要的功能&＃xff0c;在web系统&＃xff0c;日志打印等领域中有着很广泛的应用&＃xff0c;比如Flask和Django框架的代理机制就是使用了装饰器。这里&＃xff0c;我将总结《Expert Python Programming》第2版的装饰器部分我认为重点的内容&＃xff0c;并配合例子进行说明。

1、Python的装饰器&＃xff08;Decorator&＃xff09;是什么&＃xff1f;

Python装饰器&＃xff0c;简单来讲&＃xff0c;就是使函数包装和类的方法包装&＃xff08;一个函数&＃xff0c;接受函数并返回其增强函数 &＃xff08;对原函数增加一些日志信息或更高级的处理的方式&＃xff09;&＃xff09;变得容易阅读和理解。其最初的使用场景是在方法定义的开头&＃xff0c;将一个类的方法定义为静态方法/类方法——假设代码最后的staticmethod和classmethod是预先定义好的&＃xff1a;

class WithOutDecorators:def static_method_A():print("This is a static method A")def class_method_B():print("This is a class method B")# 对此静态方法进行封装 static_method_A &＃61; staticmethod(static_method_A)# 对类方法进行封装class_method_B &＃61; classmethod(class_method_B)

如果用装饰器(decorator)写的话&＃xff0c;可以想到&＃xff0c;对于有很多静态方法和类方法的类来讲&＃xff0c;采取decorator机制会使得代码可读性更强、容易理解的优点。

class WithDecorators:&＃64;staticmethoddef static_method_A():print("This is a static method A")&＃64;classmethoddef class_method_B():print("This is a class method B")

2、装饰器&＃xff08;Decorator&＃xff09;一般用法和可能实现

装饰器&＃xff08;Decorator&＃xff09;通常是一个命名的对象——&＃xff08;注意&＃xff0c;不允许使用lambda表达式&＃xff01;&＃xff09;&＃xff0c;在被装饰函数调用时&＃xff0c;接受单一参数&＃xff0c;并返回另一个可调用的对象&＃xff08;callable object&＃xff09;。所以&＃xff0c;任何可调用对象&＃xff08;类内部实现了__call__方法的对象&＃xff09;都可以用作装饰器。他们返回的对象也不是简单的函数&＃xff0c;也可能是实现了自己的__call__方法的复杂类的实例(instance)。

事实上&＃xff0c;任何函数都可以用作decorator&＃xff0c;因为python没有规定装饰器的返回类型。因此可以基于此做一些有趣的实验——比如将str()作为装饰器&＃xff0c;虽然会报错&＃xff0c;但是也是蛮有意思。

• ① 作为函数
  最简单也是最常用的用法&＃xff0c;就是编写一个函数作为Decorator&＃xff0c;通用模式为&＃xff1a;

  
# 1 装饰器函数 common useddef mydecorator(func):def wrapped(*args, **kwargs):print("调用函数之前处理...")# 在函数调用之前做一些处理result &＃61; func(*args, **kwargs)print(&＃39;函数调用完成之后处理...&＃39;)# 函数调用完成之后&＃xff0c;做点什么处理return resultreturn wrapped&＃64;mydecorator
def calc(n):assert type(n) &＃61;&＃61; int, "输入务必是integer"number &＃61; n*2print(number)return numbercalc(10)# 调用函数之前处理...# 20# 函数调用完成之后处理...

• ② 作为类
  虽然decorator总是几乎可以用函数实现&＃xff0c;但是某些情况下&＃xff0c;使用用户self-define的类可能会更好————比如需要复杂参数化或者依赖于特定状态的decorator&＃xff0c;那么这种说法往往是对的。
  通用模式如下&＃xff1a;

  # 2 装饰器作为类, 当decorator需要复杂的参数化或依赖于特定状态的时候&＃xff0c;需要这么做class DecoratorAsClass(object):def __init__(self, func):self.func &＃61; funcdef __call__(self, *args, **kwargs):# 调用原始函数之前做些什么print("类装饰器:调用函数之前处理...")result &＃61; self.func(*args, **kwargs)# 调用原始函数之后做些什么print("类装饰器:调用函数之后处理...")return result&＃64;DecoratorAsClass
def calc2(n):assert type(n) &＃61;&＃61; int, "输入务必是integer"number &＃61; n*10print(number)return numbercalc2(50)# 类装饰器:调用函数之前处理...# 500# 类装饰器:调用函数之后处理...


• ③ 参数化装饰器
  实际代码中&＃xff0c;通常需要使用参数化的装饰器。如果用函数作为装饰器的话&＃xff0c;那么解决方式很简单————需要在wrap一层&＃xff08;也就是从之前2层变成了3层&＃xff09;&＃xff1a;

  
# 3 参数化装饰器————我的理解就是在函数式装饰器基础上&＃xff0c;再加一层# 以一个重复打印的装饰器为例进行说明def repeat(number):"""多次重复执行装饰函数重复次数为number的数目。"""def actual_decorator(func):def wrapped(*args, **kwargs):result &＃61; Noneprint("参数化装饰器&＃xff1a;调用函数之前处理...")# 在函数调用之前做一些处理for i in range(number):result &＃61; func(*args, **kwargs)print(&＃39;参数化装饰器&＃xff1a;函数调用完成之后处理...&＃39;)# 函数调用完成之后&＃xff0c;做点什么处理return resultreturn wrappedreturn actual_decorator# 务必注意&＃xff0c;及时参数化decorator有默认值&＃xff0c;也必须加括号——————&＃64;repeat()&＃xff0c; 而不可以使用&＃64;repeat这种形式&＃64;repeat(3)
def calc3(n):assert type(n) &＃61;&＃61; int, "输入务必是integer"print(n)return ncalc3(100)#参数化装饰器&＃xff1a;调用函数之前处理...#100#100#100#参数化装饰器&＃xff1a;函数调用完成之后处理...


• ④ 保存内省的装饰器&＃xff08;保留被封装的原函数名称和文档&＃xff09;
  这块没细看&＃xff0c;有兴趣的同学可以看书学习。

3、装饰器&＃xff08;Decorator&＃xff09;使用和有用例子

由于装饰器在module被首次读取的时候由解释器&＃xff08;intepreter&＃xff09;来加载&＃xff0c;所以其使用受限于通用的包装器&＃xff08;wrapper&＃xff09;&＃xff0c;如果装饰器与方法的类或所增强的函数签名绑定&＃xff0c;应该将其重构为常规的可调用对象&＃xff0c;以避免复杂性。

常规的装饰器模式如下&＃xff1a;

• 参数检查
• 缓存
• 代理
• 上下文提供

&＃xff08;1&＃xff09;参数检查

其目的是&＃xff1a;检查函数接受或者返回的参数&＃xff0c;在特定的上下文中执行有用。书中的例子是&＃xff1a;“当一个函数通过XML-RPC来调用&＃xff0c;那么Python无法像静态语言C/C&＃43;&＃43;一样&＃xff0c;直接提供其完整的签名。当XML-RPC客户端请求函数签名时&＃xff0c;就需要用这功能来提供内省能力。”

也就是说&＃xff0c;在一些web应用中&＃xff0c;采用Decorator机制的参数检查会发挥作用&＃xff0c;这块我暂时没看。

&＃xff08;2&＃xff09;缓存

缓存和参数检查十分相似&＃xff0c;不过&＃xff0c;它重点关注的是不受状态影响的函数&＃xff0c;即唯一确定的参数一定会产生唯一确定的结果&＃xff0c;这就是函数式编程&＃xff08;functional programming&＃xff09;的风格。

因此&＃xff0c;缓存decorator可以将输出与计算其所需要的参数放在一起&＃xff0c;并在后续的调用中直接返回它。这种行为被称为memoizing。
下面就是一个装饰器的实现&＃xff0c;其中
is_obsolete函数是判断某组&＃xff08;函数&＃xff0c;参数&＃xff09;的计算结果是否超过cache的固定时间&＃xff0c;如果超过就返回yes。
compute_key的作用是计算某组&＃xff08;函数&＃xff0c;参数&＃xff09;的签名。

一个明显的问题就是&＃xff0c;cache到时了&＃xff0c;字典中对应的结果没被擦除&＃xff0c;这块可以根据自己的需要个性定制。有想更深入学习缓存装饰器的&＃xff0c;建议看一下functools里面的lru_cache&＃xff0c;它也是以装饰器的形式使用。网上也有比较详实的说明介绍。

&＃xff08;3&＃xff09;代理&＃xff08;Web&＃xff09;

代理装饰器使用全局机制来标记和注册函数。举个例子&＃xff0c;一个根据当前用户来保护代码访问的安全层可以使用集中式检查器和相关的可调用对象要求的权限来实现。

这种模型通常用于Python的Web框架中&＃xff0c;用于定义可发布类的安全性。例如&＃xff0c;Django提供decorator来保护函数访问的安全。

下面的简单例子是&＃xff0c;当前用户被保存在全局变量&＃xff08;用到了python的全局机制&＃xff0c;globals())。在方法被访问的时候decorator会检查其角色&＃xff0c;看是否符合。

对复杂情况&＃xff0c;可以对每个角色的分工设置权限&＃xff0c;比如某个用户只能看到网页A,B&＃xff0c;而root用户能看到网页A,B,C,D这种设置。

&＃xff08;4&＃xff09; 上下文提供者&＃xff08;通常被上下文管理器(with …)所替代&＃xff09;

上下文装饰器确保函数可以运行在正确的上下文中&＃xff0c;或者在函数前后运行一些代码。换句话说&＃xff0c;它设定并复位一个特定的执行环境。

举个例子&＃xff0c;当一个数据需要在多个thread之间进行共享的时候&＃xff0c;需要锁来保护它被多次访问&＃xff08;临界区&＃xff09;。这个锁可以在装饰器中编写&＃xff0c;代码如下&＃xff1a;