转自:http://blog.csdn.net/mdl13412/article/details/22608283
前置知识
一级对象
Python将一切视为 objec t的子类,即一切都是对象,因此函数可以像变量一样被指向和传递,我们来看下面的例子:
其运行结果如下:
- def foo():
- pass
- print issubclass(foo.__class__, object)
上述代码说明了Python 中的函数是 object 的子类,下面让我们看函数被当作参数传递时的效果:
- True
其运行结果如下:
- def foo(func):
- func()
- def bar():
- print "bar"
- foo(bar)
- bar
Python中的namespace
Python中通过提供 namespace 来实现重名函数/方法、变量等信息的识别,其一共有三种 namespace,分别为:
- local namespace: 作用范围为当前函数或者类方法
- global namespace: 作用范围为当前模块
- build-in namespace: 作用范围为所有模块
当函数/方法、变量等信息发生重名时,Python会按照 local namespace -> global namespace -> build-in namespace的顺序搜索用户所需元素,并且以第一个找到此元素的 namespace 为准。
下面以系统的 build-in 函数 str 为例进行说明:
首先定义三个 global namespace 的函数 str、 foo 和 bar,然后在 foo 函数中定义一个内嵌的 local namespace 的函数 str,然后在函数 foo 和 bar 中分别调用 str("dummy"),其运行结果如下所示:
- def str(s):
- print "global str()"
- def foo():
- def str(s):
- print "closure str()"
- str("dummy")
- def bar():
- str("dummy")
- foo()
- bar()
通过编码实验,我们可以看到:
- closure str()
- global str()
下面我们使用Python内置的 `ocals() 和 globals() 函数查看不同 namespace 中的元素定义:
- foo 中调用 str 函数时,首先搜索 local namespace,并且成功找到了所需的函数,停止搜索,使用此namespace 中的定义
- bar 中调用 str 函数时,首先搜索 local namespace,但是没有找到str 方法的定义,因此继续搜索 global namespace,并成功找到了str 的定义,停止搜索,并使用此定义
运行结果如下:
- var = "var in global"
- def fun():
- var = "var in fun"
- print "fun: " + str(locals())
- print "globals: " + str(globals())
- fun()
通过运行结果,我们看到了 fun 定义了 local namespace 的变量 var,在 global namespace 有一个全局的 var 变量,那么当在 global namespace 中直接访问 var 变量的时候,将会得到 var = "var in global" 的定义,而在 fun 函数的 local namespace 中访问 var 变量,则会得到 fun 私有的 var = "var in fun" 定义。
- globals: { '__builtins__': <module '__builtin__' (built-in)>, '__file__': 'a.py', '__package__': None, 'fun': <function fun at 0x7f2ca74f66e0>, 'var': 'var in global', '__name__': '__main__', '__doc__': None}
- fun: { 'var': 'var in fun'}
*args and **kwargs
- *args: 把所有的参数按出现顺序打包成一个 list
- **kwargs:把所有 key-value 形式的参数打包成一个 dict
下面给出一个 *args 的例子:
其运行结果如下:
- params_list = (1, 2)
- params_tupple = (1, 2)
- def add(x, y):
- print x + y
- add(*params_list)
- add(*params_tupple)
**kwargs 的例子:
- 3
- 3
其运行结果如下:
- params = {
- 'x': 1,
- 'y': 2
- }
- def add(x, y):
- print x + y
- add(**params)
- 3
闭包
下面给出一个使用闭包实现的 logger factory的例子:
- <a target="_blank" href="http://zh.wikipedia.org/zh-cn/%E9%97%AD%E5%8C%85_(%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%A7%91%E5%AD%A6)">闭包在维基百科上的定义</a>如下: 在计算机科学中,闭包(Closure)是词法闭包(Lexical Closure)的简称,是引用了自由变量的函数。这个被引用的自由变量将和这个函数一同存在,即使已经离开了创造它的环境也不例外。所以,有另一种说法认为闭包是由函数和与其相关的引用环境组合而成的实体。
其运行结果如下:
- def logger_facroty(prefix="", with_prefix=True):
- if with_prefix:
- def logger(msg):
- print prefix + msg
- return logger
- else:
- def logger(msg):
- print msg
- return logger
- logger_with_prefix = logger_facroty("Prefix: ")
- logger_without_prefix = logger_facroty(with_prefix=False)
- logger_with_prefix("msg")
- logger_without_prefix("msg")
在上面这个闭包的例子中, prefix 变量时所谓的自由变量,其在 return logger 执行完毕后,便脱离了创建它的环境 logger_factory,但因为其被 logger_factory 中定义的 logger 函数所引用,其生命周期将至少和 logger 函数相同。这样,在 logger 中就可以引用到 logger_factory 作用域内的变量 prefix。
- Prefix: msg
- msg
将闭包与 namespace 结合起来:
其运行结果如下:
- var = "var in global"
- def fun_outer():
- var = "var in fun_outer"
- unused_var = "this var is not used in fun_inner"
- print "fun_outer: " + var
- print "fun_outer: " + str(locals())
- print "fun_outer: " + str(id(var))
- def fun_inner():
- print "fun_inner: " + var
- print "fun_inner: " + str(locals())
- print "fun_inner: " + str(id(var))
- return fun_inner
- fun_outer()()
在这个例子中,当 fun_outer 被定义时,其内部的定义的 fun_inner 函数对 print "fun_inner: " + var中所引用的 var 变量进行搜索,发现第一个被搜索到的 var 定义在 fun_outer 的 local namespace 中,因此使用此定义,通过 print "fun_outer: " + str(id(var)) 和 print "fun_inner: " + str(id(var)),当 var 超出 fun_outer 的作用域后,依然存活,而 fun_outer 中的 unused_var 变量由于没有被 fun_inner 所引用,因此会被 GC。
- fun_outer: var in fun_outer
- fun_outer: { 'var': 'var in fun_outer', 'unused_var': 'this var is not used in fun_inner'}
- fun_outer: 140228141915584
- fun_inner: var in fun_outer
- fun_inner: { 'var': 'var in fun_outer'}
- fun_inner: 140228141915584
探索装饰器
定义
- <a target="_blank" href="http://en.wikipedia.org/wiki/Python_syntax_and_semantics#Decorators">点击打开装饰器在维基百科上的定义链接</a>如下: A decorator is any callable Python object that is used to modify a function, method or class definition.
基本语法
语法糖
其等价于:
- @bar
- def foo():
- print "foo"
- def foo():
- print "foo"
- foo = bar(foo)
无参数装饰器
foo 函数被用作装饰器,其本身接收一个函数对象作为参数,然后做一些工作后,返回接收的参数,供外界调用。
- def foo(func):
- print 'decorator foo'
- return func
- @foo
- def bar():
- print 'bar'
- bar()
注意: 时刻牢记 @foo 只是一个语法糖,其本质是 foo = bar(foo)
带参数装饰器
上述代码想要实现一个性能分析器,并接收一个参数,来控制性能分析器是否生效,其运行效果如下所示:
- import time
- def function_performance_statistics(trace_this=True):
- if trace_this:
- def performace_statistics_delegate(func):
- def counter(*args, **kwargs):
- start = time.clock()
- func(*args, **kwargs)
- end =time.clock()
- print 'used time: %d' % (end - start, )
- return counter
- else:
- def performace_statistics_delegate(func):
- return func
- return performace_statistics_delegate
- @function_performance_statistics(True)
- def add(x, y):
- time.sleep(3)
- print 'add result: %d' % (x + y,)
- @function_performance_statistics(False)
- def mul(x, y=1):
- print 'mul result: %d' % (x * y,)
- add(1, 1)
- mul(10)
上述代码中装饰器的调用等价于:
- add result: 2
- used time: 0
- mul result: 10
- add = function_performance_statistics(True)(add(1, 1))
- mul = function_performance_statistics(False)(mul(10))
类的装饰器
类的装饰器不常用,因此只简单介绍。
上述代码的 inject 装饰器为类动态的添加一个 bar 方法,因为类在调用非静态方法的时候会传进一个 self 指针,因此 bar 的第一个参数我们简单的忽略即可,其运行结果如下:
- def bar(dummy):
- print 'bar'
- def inject(cls):
- cls.bar = bar
- return cls
- @inject
- class Foo(object):
- pass
- foo = Foo()
- foo.bar()
- bar
类装饰器
类装饰器相比函数装饰器,具有灵活度大,高内聚、封装性等优点。其实现起来主要是靠类内部的 __call__ 方法,当使用 @ 形式将装饰器附加到函数上时,就会调用此方法,下面时一个实例:
其运行结果如下:
- class Foo(object):
- def __init__(self, func):
- super(Foo, self).__init__()
- self._func = func
- def __call__(self):
- print 'class decorator'
- self._func()
- @Foo
- def bar():
- print 'bar'
- bar()
- class decorator
- bar
内置装饰器
Python中内置的装饰器有三个: staticmethod、classmethod 和property
staticmethod 是类静态方法,其跟成员方法的区别是没有 self 指针,并且可以在类不进行实例化的情况下调用,下面是一个实例,对比静态方法和成员方法
其运行结果如下:
- class Foo(object):
- @staticmethod
- def statc_method(msg):
- print msg
- def member_method(self, msg):
- print msg
- foo = Foo()
- foo.member_method('some msg')
- foo.statc_method('some msg')
- Foo.statc_method('some msg')
classmethod 与成员方法的区别在于所接收的第一个参数不是 self 类实例的指针,而是当前类的具体类型,下面是一个实例:
- some msg
- some msg
- some msg
其运行结果如下:
- class Foo(object):
- @classmethod
- def class_method(cls):
- print repr(cls)
- def member_method(self):
- print repr(self)
- foo = Foo()
- foo.class_method()
- foo.member_method()
property 是属性的意思,即可以通过通过类实例直接访问的信息,下面是具体的例子:
- <class '__main__.Foo'>
- <__main__.Foo object at 0x10a611c50>
注意: 如果将上面的 @var.setter 装饰器所装饰的成员函数去掉,则 Foo.var 属性为只读属性,使用 foo.var = 'var 2' 进行赋值时会抛出异常,其运行结果如下:
- class Foo(object):
- def __init__(self, var):
- super(Foo, self).__init__()
- self._var = var
- @property
- def var(self):
- return self._var
- @var.setter
- def var(self, var):
- self._var = var
- foo = Foo('var 1')
- print foo.var
- foo.var = 'var 2'
- print foo.var
注意: 如果使用老式的Python类定义,所声明的属性不是 read only的,下面代码说明了这种情况:
- var 1
- var 2
其运行结果如下:
- class Foo:
- def __init__(self, var):
- self._var = var
- @property
- def var(self):
- return self._var
- foo = Foo('var 1')
- print foo.var
- foo.var = 'var 2'
- print foo.var
- var 1
- var 2
调用顺序
装饰器的调用顺序与使用 @ 语法糖声明的顺序相反,如下所示:
其等价于:
- def decorator_a(func):
- print "decorator_a"
- return func
- def decorator_b(func):
- print "decorator_b"
- return func
- @decorator_a
- @decorator_b
- def foo():
- print "foo"
- foo()
通过等价的调用形式我们可以看到,按照python的函数求值序列, decorator_b(fun) 会首先被求值,然后将其结果作为输入,传递给 decorator_a,因此其调用顺序与声明顺序相反。其运行结果如下所示:
- def decorator_a(func):
- print "decorator_a"
- return func
- def decorator_b(func):
- print "decorator_b"
- return func
- def foo():
- print "foo"
- foo = decorator_a(decorator_b(foo))
- foo()
- decorator_b
- decorator_a
- foo
调用时机
装饰器很好用,那么它什么时候被调用?性能开销怎么样?会不会有副作用?接下来我们就以几个实例来验证我们的猜想。
首先我们验证一下装饰器的性能开销,代码如下所示:其运行结果如下:
- def decorator_a(func):
- print "decorator_a"
- print 'func id: ' + str(id(func))
- return func
- def decorator_b(func):
- print "decorator_b"
- print 'func id: ' + str(id(func))
- return func
- print 'Begin declare foo with decorators'
- @decorator_a
- @decorator_b
- def foo():
- print "foo"
- print 'End declare foo with decorators'
- print 'First call foo'
- foo()
- print 'Second call foo'
- foo()
- print 'Function infos'
- print 'decorator_a id: ' + str(id(decorator_a))
- print 'decorator_b id: ' + str(id(decorator_b))
- print 'fooid : ' + str(id(foo))
在运行结果中的:
- Begin declare foo with decorators
- decorator_b
- func id: 140124961990488
- decorator_a
- func id: 140124961990488
- End declare foo with decorators
- First call foo
- foo
- Second call foo
- foo
- Function infos
- decorator_a id: 140124961954464
- decorator_b id: 140124961988808
- fooid : 140124961990488
证实了装饰器的调用时机为: 被装饰对象定义时
- Begin declare foo with decorators
- decorator_b
- func id: 140124961990488
- decorator_a
- func id: 140124961990488
- End declare foo with decorators
而运行结果中的:
证实了在相同 .py 文件中,装饰器对所装饰的函数只进行一次装饰,不会每次调用相应函数时都重新装饰,这个很容易理解,因为其本质等价于下面的函数签名重新绑定:
- First call foo
- foo
- Second call foo
- foo
对于跨模块的调用,我们编写如下结构的测试代码:
- foo = decorator_a(decorator_b(foo))
上述所有模块中的 __init__.py 文件均为: # -*- coding: utf-8 -*-
- .
- ├── common
- │ ├── decorator.py
- │ ├── __init__.py
- │ ├── mod_a
- │ │ ├── fun_a.py
- │ │ └── __init__.py
- │ └── mod_b
- │ ├── fun_b.py
- │ └── __init__.py
- └── test.py
- # -*- coding: utf-8 -*-
- # common/mod_a/fun_a.py
- from common.decorator import foo
- def fun_a():
- print 'in common.mod_a.fun_a.fun_a call foo'
- foo()
- # -*- coding: utf-8 -*-
- # common/mod_b/fun_b.py
- from common.decorator import foo
- def fun_b():
- print 'in common.mod_b.fun_b.fun_b call foo'
- foo()
- # -*- coding: utf-8 -*-
- # common/decorator.py
- def decorator_a(func):
- print 'init decorator_a'
- return func
- @decorator_a
- def foo():
- print 'function foo'
上述代码通过创建 common.mod_a 和 common.mod_b 两个子模块,并调用 common.decorator 中的 foo 函数,来测试跨模块时装饰器的工作情况,运行 test.py 的结果如下所示:
- # -*- coding: utf-8 -*-
- # test.py
- from common.mod_a.fun_a import fun_a
- from common.mod_b.fun_b import fun_b
- fun_a()
- fun_b()
经过上面的验证,可以看出,对于跨模块的调用,装饰器也只会初始化一次,不过这要归功于 *.pyc,这与本文主题无关,故不详述。
- init decorator_a
- in common.mod_a.fun_a.fun_a call foo
- function foo
- in common.mod_b.fun_b.fun_b call foo
- function foo
关于装饰器副作用的话题比较大,这不仅仅是装饰器本身的问题,更多的时候是我们设计上的问题,下面给出一个初学装饰器时大家都会遇到的一个问题——丢失函数元信息:
其运行结果如下所示:
- def decorator_a(func):
- def inner(*args, **kwargs):
- res = func(*args, **kwargs)
- return res
- return inner
- @decorator_a
- def foo():
- '''''foo doc'''
- return 'foo result'
- print 'foo.__module__: ' + str(foo.__module__)
- print 'foo.__name__: ' + str(foo.__name__)
- print 'foo.__doc__: ' + str(foo.__doc__)
- print foo()
我们可以看到,在使用 decorator_a 对 foo 函数进行装饰后,foo 的元信息会丢失,解决方案参见: functools.wraps
- foo.__module__: __main__
- foo.__name__: inner
- foo.__doc__: None
- foo result
多个装饰器运行期行为
前面已经讲解过装饰器的调用顺序和调用时机,但是被多个装饰器装饰的函数,其运行期行为还是有一些细节需要说明的,而且很可能其行为会让你感到惊讶,下面时一个实例:
大家先来看一下运行结果,看看是不是跟自己想象中的一致:
- def tracer(msg):
- print "[TRACE] %s" % msg
- def logger(func):
- tracer("logger")
- def inner(username, password):
- tracer("inner")
- print "call %s" % func.__name__
- return func(username, password)
- return inner
- def login_debug_helper(show_debug_info=False):
- tracer("login_debug_helper")
- def proxy_fun(func):
- tracer("proxy_fun")
- def delegate_fun(username, password):
- tracer("delegate_fun")
- if show_debug_info:
- print "username: %s\npassword: %s" % (username, password)
- return func(username, password)
- return delegate_fun
- return proxy_fun
- print 'Declaring login_a'
- @logger
- @login_debug_helper(show_debug_info=True)
- def login_a(username, password):
- tracer("login_a")
- print "do some login authentication"
- return True
- print 'Call login_a'
- login_a("mdl", "pwd")
首先,装饰器初始化时的调用顺序与我们前面讲解的一致,如下:
- Declaring login_a
- [TRACE] login_debug_helper
- [TRACE] proxy_fun
- [TRACE] logger
- Call login_a
- [TRACE] inner
- call delegate_fun
- [TRACE] delegate_fun
- username: mdl
- password: pwd
- [TRACE] login_a
- do some login authentication
然而,接下来,来自 logger 装饰器中的 inner 函数首先被执行,然后才是 login_debug_helper 返回的 proxy_fun 中的 delegate_fun 函数。各位读者发现了吗,运行期执行 login_a 函数的时候,装饰器中返回的函数的执行顺序是相反的,难道是我们前面讲解的例子有错误吗?其实,如果大家的认为运行期调用顺序应该与装饰器初始化阶段的顺序一致的话,那说明大家没有看透这段代码的调用流程,下面我来为大家分析一下。
- Declaring login_a
- [TRACE] login_debug_helper
- [TRACE] proxy_fun
- [TRACE] logger
当装饰器 login_debug_helper 被调用时,其等价于:
- def login_debug_helper(show_debug_info=False):
- tracer("login_debug_helper")
- def proxy_fun(func):
- tracer("proxy_fun")
- def delegate_fun(username, password):
- tracer("delegate_fun")
- if show_debug_info:
- print "username: %s\npassword: %s" % (username, password)
- return func(username, password)
- return delegate_fun
- return proxy_fun
对于只有 login_debug_helper 的情况,现在就应该是执行玩 login_a输出结果的时刻了,但是如果现在在加上 logger 装饰器的话,那么这个 login_debug_helper(show_debug_info=True)(login_a)('mdl', 'pwd')就被延迟执行,而将 login_debug_helper(show_debug_info=True)(login_a) 作为参数传递给 logger,我们令 login_tmp = login_debug_helper(show_debug_info=True)(login_a),则调用过程等价于:
- login_debug_helper(show_debug_info=True)(login_a)('mdl', 'pwd')
相信大家看过上面的等价变换后,已经明白问题出在哪里了,如果你还没有明白,我强烈建议你把这个例子自己敲一遍,并尝试用自己的方式进行化简,逐步得出结论。
- login_tmp = login_debug_helper(show_debug_info=True)(login_a)
- login_a = logger(login_tmp)
- login_a('mdl', 'pwd')
一些实例参考
本文主要讲解原理性的东西,具体的实例可以参考下面的链接:
Python装饰器实例:调用参数合法性验证Python装饰器与面向切面编程
Python装饰器小结
Python tips: 超时装饰器, @timeout decorator
python中判断一个运行时间过长的函数
python利用装饰器和threading实现异步调用
python输出指定函数运行时间的装饰器
python通过装饰器和线程限制函数的执行时间
python装饰器的一个妙用
通过 Python 装饰器实现DRY(不重复代码)原则
参考资料
Understanding Python Decorators in 12 Easy Steps
Decorators and Functional Python
Python Wiki: PythonDecorators
Meta-matters: Using decorators for better Python programming
Python装饰器入门(译)
Python装饰器与面向切面编程
Python 的闭包和装饰器
Python装饰器学习(九步入门)
python 装饰器和 functools 模块