[译] Python装饰器Part I:装饰器简介

假以时日,我相信装饰器一定会成为Python这门编程语言一个更加强大的功能。到目前为止,我觉得到我所看到的有关介绍Python装饰器的文章都或多或少地会让人觉得困惑,所以在这儿尝试看能否修正这些问题。

装饰器 vs 装饰器模式

首先,大家需要明白的是使用装饰器这个词可能会有不少让大家担忧的地方,因为它很容易和设计模式这本书里面的装饰器模式发生混淆。曾经一度考虑给这个新的功能取一些其它的术语名称,但是装饰器最终还是胜出了。
的确,你可以使用python装饰器来实现装饰器模式,但这绝对是它很小的一部分功能,有点暴殄天物。对于python装饰器,我觉得它是最接近的存在。

宏的历史

有有着非常悠久的历史,不过大多数人可能会有使用C语言预处理宏的经验。但是,对于C语言里的宏来说,它存在一些问题,(1)宏并不存在于C语言中,(2)而且宏的行为有时候会有点诡异,而且经常会和C语言的行为不太一致。
为了支持对语言本身的一些元素进行操作,Java和C#都添加了注解。当然他们也都存在一些问题:有时候为了达到自己的目的,你不得不绕过很多的坑。还没完,这些注解特性还会受到这些语言的一些与生俱来的特性的束手束脚(就像Martin Fowler所描述的 “Directing”
稍有不同的是,包括我在内的很多C++程序员已经意识到C++模板的威力,也已经在像使用宏一样在使用这个功能。
很多其他的语言也都包含宏的功能,尽管了解的并不多,我还是愿意大言不惭的说,python装饰器无论在功能的强大还是丰富性方面都和Lisp的宏很相似。

宏的目标

我觉得,这样对进行描述并不过分:一门编程语言中宏的存在是为了提供操作语言元素本身的能力。这恰恰也是python装饰器能做的事情,它们能够对函数进行修改,也能对这个类进行装饰。相比复杂的元类,这也许是大家经常提供一个简单的装饰器的原因吧。
大多数编程语言所提供的能进行自我修改(元编程)的方案都有一个主要的缺点,那就是限制和束缚太多,写着写着有种在写其它语言的错觉。
Python符合Martin Fowler所说的“Enabling”编程语言。所以说,如果你想进行修改操作(元编程),为毛还要弄出一门”不一样“或者”限制多多“的语言呢?为什么不直接抄起python自己咔咔就直接开始干呢?这就是python装饰器能做的。

能用Python装饰器做些什么

装饰器能够让你“注入”或者”修改“函数或者类里面的代码(逻辑)。除了更加简单和强大之外,装饰器听起来有点像AOP面向方面编程的感觉对吧。举例来说,加入你想在方法的开始或者结束前做一些事情(比如一些类似于权限检查、跟踪、资源加锁等一些面向方面编程里的常规操作)。有了装饰器,你可以这么做:

@entryExit
def func1():
    print "inside func1()"

@entryExit
def func2():
    print "inside func2()"

函数的装饰器

函数式装饰器通常会被放在一个函数定义的代码前来应用合格装饰器,比如:

@myDecorator
def aFunction():
    print "inside aFunction"

当编译器走到这段代码的时候,函数aFunction会被编译,编译得到的函数对象会传递给myDecorator,装饰器会生成一个新的函数对象来替换原有的函数aFunction
那么,装饰器myDecorator的代码实现是怎样的呢?尽管大多数的装饰器入门示例都会写一个函数,但是我发现,相比函数式装饰器,类式装饰器能更好的帮助理解,而且它更加强大。
唯一需要确保的是,装饰器返回的对象要是像函数一样能够被调用的,因此类式装饰器需要实现__call__
装饰器应该要完成什么工作呢?好吧,它能够做任何事情,不过通常情况下,你可能会期望原有的被传递来的函数在某个地方能够被执行,尽管这不是强制的:

class myDecorator(object):

    def __init__(self, f):
        print "inside myDecorator.__init__()"
        f() # Prove that function definition has completed

    def __call__(self):
        print "inside myDecorator.__call__()"

@myDecorator
def aFunction():
    print "inside aFunction()"

print "Finished decorating aFunction()"

aFunction()

当你执行这段代码的时候,你会看到这样的输出:

inside myDecorator.__init__()
inside aFunction()
Finished decorating aFunction()
inside myDecorator.__call__()

请注意,myDecorator的构造器实际是在装饰函数的时候执行的。我们可以在__init__()里面调用函数f,能够看到,在装饰器被调用之前,函数调用f()就已经完成了。另外,装饰器的构造器能够接收被装饰的方法。一般来讲,我们会捕捉到这个函数对象然后接下来在函数__call__()里面调用。装饰和调用是两个非常清晰明了的不同的步骤,这也是我为什么说类似装饰器更简单同时也更强大的原因。
当函数aFunction被装饰完成然后调用的时候,我们得到了一个完全不同的行为,实际上执行的是myDecorator.__call__()的代码逻辑,这是因为”装饰“把原有的代码逻辑用新的返回的逻辑给替换掉了。在我们的例子中,myDecorator对象替换掉了函数aFunction。事实上,在装饰器操作符@被加入之前,你不得不做一些比较low的操作来完成同样的事情:

def foo(): pass
foo = staticmethod(foo)

因为有了@这个装饰器操作符, 你可以非常优雅的得到同样的结果:

@staticmethod
def foo(): pass

不过也有不少人因为这一点反对装饰器,不过@仅仅是一个很小的语法糖而已,把一个函数对象传递给另外一个函数,然后用返回值替换原有的方法。
我觉着,之所以装饰器会产生这么大的影响是因为这个小小的语法糖完全改变了人们思考编程的方式。的确,通过将它实现成一个编程语言结构,它将”代码应用到代码上面“的思想带到了主流编程思维层面。

青出于蓝

现在我们实现一下第一个例子。在这里我们将会做一些很常规的事情,并且会使用这些代码:

class entryExit(object):

    def __init__(self, f):
        self.f = f

    def __call__(self):
        print "Entering", self.f.__name__
        self.f()
        print "Exited", self.f.__name__

@entryExit
def func1():
    print "inside func1()"

@entryExit
def func2():
    print "inside func2()"

func1()
func2()

运行结果是:

Entering func1
inside func1()
Exited func1
Entering func2
inside func2()
Exited func2

现在我们能够看到,那些被装饰的方法有了“进入”和“离开”的跟踪信息。
构造器存储了通过参数传递进来的函数对象,在调用的方法里,我们用函数对象的__name__属性来展示被调用函数的名称,然后调用被装饰的函数自己。

使用函数作为装饰器

对于装饰器返回结果的约束只有一个,那就是能够被调用,从而它能够合理的替换掉原有的被装饰的那个函数。在上面的这些例子中,我们是将原有的函数用包含有__call__()的对象替换的。一个函数对象同样能够被调用,所以我们可以用函数来重写前一个装饰器的例子,像这样:

def entryExit(f):
    def new_f():
        print "Entering", f.__name__
        f()
        print "Exited", f.__name__
    return new_f

@entryExit
def func1():
    print "inside func1()"

@entryExit
def func2():
    print "inside func2()"

func1()
func2()
print func1.__name__

函数new_f()嵌套定义在entryExit的方法体里面,当entryExit被调用的时候,new_f()也会顺理成章地被返回。值得注意的是new_f()是一个闭包,捕获了参数变量f的值。
new_f()定义完成后,它将会被entryExit返回,然后装饰器机制发生作用将结果赋值成被装饰的新方法。
代码print func1.__name__的输出结果是new_f,因为在装饰发生的过程中,原来的方法已经被替换成了new_f,如果对你来说这是一个问题的话,你可以在装饰器返回结果之前修改掉函数的名字:

def entryExit(f):
    def new_f():
        print "Entering", f.__name__
        f()
        print "Exited", f.__name__
    new_f.__name__ = f.__name__
    return new_f

你可以动态的获取函数的信息包括那些你做的更改,这在python里面非常有用。

更多示例

现在你已经基本有了一个概念,你可以在这里找到更多装饰器的例子,这些例子都是使用的类式装饰器,不是函数式装饰器。
在这篇文章中,我故意没有涉及到带参数的被装饰方法,我们下回分解。

下一篇:Python装饰器Part II:装饰器参数

[注] “Directing”“Enabling” 是Martin Fowler总结的两种软件开发态度,简单描述下就是:“大部分的开发人员可能比较菜,需要创建约束让开发人员少犯错误,更加规范” vs “让开发人员自己负责,更加自由,当然自己犯的错含着泪也要自己搞定”。
原文地址:Decorators I: Introduction to Python Decorators

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,029评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,395评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,570评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,535评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,650评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,850评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,006评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,747评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,207评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,536评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,683评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,342评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,964评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,772评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,004评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,401评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,566评论 2 349

推荐阅读更多精彩内容