先说结论java 注解能实现的功能python 的装饰器绝大部分都是可以胜任的装饰器更像 Java 中注解加上Aop两者的组合python 是一门极简的语言语言简洁学习起来也是相当轻松的但是依然有一些高级技巧例如装饰器协程并发会让人感觉困惑失望与沮丧本文将重点讲解 python装饰器的使用使用常用的例子让我们更直观的看到装饰器的强大表达能力最后也给出了编写装饰器常见的工具。熟悉 java的同学一定熟悉注解的使用借助于注解可以定义元数据配置我们常常有这种感受“只要加上这个注解我的组件就会被注册进去”“只要加上这个注解就会添加事务控制”也会困惑“为什么加了这个注解依然没有生效?” python 没有提供像Java似的注解但是提供了相比注解表达能力更加强大的装饰器。例如 web框架 Flask 中的route errorhandler及 python 自带的 propertystaticmethod等。 实际上java 注解能实现的功能python 的装饰器绝大部分都是可以胜任的装饰器更像 Java 中注解加上Aop两者的组合 这个结论最后我们会重点讨论先按下不表。现在首先以日志打印的简单例子初步讲解一下装饰器的使用1.0 装饰器的简单例子def log(func): #1 def func_dec(*args, **kwargs): #2 r func(*args, **kwargs) #3 print(didiyun execute done:%s % func.__name__) return r return func_dec log #4 def test_dec(size, length, kyNone): print didiyun execute test_dec param:%s, %s, %s % (size, length, ky) def test(): test_dec(kyyuhaiqiang, length3, size1) 输出结果可以看到装饰器的装饰逻辑已正确被执行 didiyun execute test_dec param:1, 3, yuhaiqiang didiyun execute done:test_dec 1 定义 log 装饰器输入参数func是需要被装饰的函数本例中输出打印是 test_dec 2 定义一个装饰函数参数类型包括变长的位置参数和名字参数适应被装饰函数不同的参数组合这种写法可以代表任意参数组合 3 执行实际的函数func_dec 注意处理返回值不要吞掉被装饰函数的返回值 4 在被装饰函数上添加装饰器注意此处不要加()后面会解释具体原因了解该原因就能完全了解装饰器的小九九装饰器可以在函数外层添加额外的功能装饰原函数 本例的装饰器只是在函数外层打印一行日志实现的是非常简单的功能实际中装饰器并不是仅仅打印日志的雕虫小技还能实现其他更有用的功能2.使用装饰器巧用文件锁2.1 使用 fcntl 实现文件锁class Lock: def __init__(self, filename, blockTrue): #block 参数为 true代表阻塞式获取。 False为非阻塞如果获取不到立刻返回 false self.filename filename self.block block self.handle open(filename, w) def acquire(self): if not self.block: try: fcntl.flock(self.handle, fcntl.LOCK_EX | fcntl.LOCK_NB) return True except: return False else: fcntl.flock(self.handle, fcntl.LOCK_EX) return True def release(self): fcntl.flock(self.handle, fcntl.LOCK_UN) self.handle.close()借助于 fcntl 库 我们已经实现文件锁感兴趣的读者可以深入了解一下 fcntl 库下面我们以文件锁为例介绍一下装饰器很实用很常见的一些功能。2.2 定义文件锁装饰器def file_lock(lock_name, blockTrue): #1 def wrapper(func): def f(*args, **kwargs): name lock_name lock Lock(name, block) acquire lock.acquire() if not acquire: print(failed to acquire lock:%s,now ignore % name) return #2 print(acquire process lock:%s % name) try: return func(*args, **kwargs) finally: lock.release() #3 print(release process lock:%s % name) return f return wrapper file_lock(name/var/local/file, blockTrue) #4 def get_length(): pass get_length() 输出 #5 acquire process lock:/var/local/file execute test_dec param:1 release process lock:/var/local/file定义 file_lock 装饰器接受两个参数 lock_name:锁路径 block: 是否阻塞式的获取该处在获取锁失败时仅仅返回了 None 调用方无法 明确知道None 是 get_length 的返回值还是获取锁失败实际上应该抛出一个异常交给上游调用方去处理 获取锁操作失败的异常try finally 保证锁一定可以被释放在使用文件锁的时候还需要提供锁的值能否提供默认值呢?只对该实例方法加锁读者可以考虑一下如何实现。此外细心地读者能比较出来file_lock装饰器添加了括号()但是两者的区别可不仅仅因为一个有参数一个无参后一节解释下装饰器的语法糖本质实际在项目中使用时经常会遇到文件锁的问题 在项目调试阶段 由于经常需要手动终止强杀程序 这样会导致文件锁没有被正确清理读者可以考虑将文件锁指定在一个固定的目录 每次进程启动时检测是否有同路径进程如果没有 可以清理该目录如果存在同路径进程说明现在有并发执行不清理该目录。 如果没有清理功能可能会导致永远无法获取到锁。 如果不实际使用以上代码实现文件锁可以忽略该问题不影响理解装饰器。 感兴趣的读者可以试试希望能提出更好的文件锁方案使用文件锁之后调用该方法必须先获取到锁否则只能先阻塞。 因此实际的处理方法不需要处理同步逻辑 只需要一行装饰器 就额外扩展了同步功能 通过异常控制还能保证文件锁一定可以被释放 避免文件锁泄露 通过装饰器我们还可以实现很多其他有用的功能但是文件锁装饰器的实现已经相比日志装饰器复杂了 仔细观察 它已经 嵌套了 三层函数后续我们会优化这个问题。2.3 解释1.0 的疑问何时使用装饰器需要添加 括号()在1.0 日志装饰器的例子我们留下了一个疑问为什么 log 装饰器不需要加() 而文件锁装饰器的使用却加了()回到1.0 的装饰器实现假如我们不使用 log 的方式使用如下方式呢?能不能实现相同的逻辑?log def foo(): pass foo() # 相当于 log(foo)()log(func) 返回装饰函数最后的括号代表执行 foo log(foo) # 就是装饰器语法糖帮我们做的log 方法接受的参数是 func 自然当手动显式 调用 log 装饰 foo 函数时 丝毫不影响实现装饰的功能. 但是显得我们很啰嗦很蠢 幸福的是 python提供了装饰器的语法糖 使用该语法糖就好像我们手动执行装饰一样。 但是如果我们加上括号代表什么意思呢? log() 的写法 不就相当于调用了 log 函数但是又不给其传参?实际 python 解释器也是这么抗议 我们的。但是为什么文件锁又加上了括号呢?答案是装饰器有时候需要一些额外的参数例如 Flask 中我们常用的 route我们需要告诉 Flask 如何 将url映射到具体的 handler 自然需要告诉 route 需要绑定的 url 是什么 和 spring 的RequestMapping作用类似当装饰器加上参数之后 惊讶的发现装饰器更像是三层函数了… 可理解性已经极差了 但是一旦理解之后我们会发现三层函数是原因的不妨这样理解 当装饰器没有参数 就像log 装饰器该装饰器接受参数为 func 我们称其为两层装饰器 以上我们已经分析了它的的原理foo log(foo). 装饰器的标记等于告诉 python解释器 “你把下一行的函数作为参数传给该装饰器然后把返回值赋值给该函数” 相当于执行 foo log(foo)当我们调用 foo() 相当于是调用 log(foo)()。对于带参数的装饰器file_lock(nameblock) 我们分成两个阶段理解回顾一下 file_lock 的三层函数实现我们在第二层定义了一个 wrapper 函数该函数接受了一个 func 参数,随后我们在 file_lock的最后将其return 我们可以这样认为file_lock(name/var/local/test,blockTrue) def test() pass wrapper file_lock(name, block) #第一阶段 test wrapper(test) #第二阶段第一阶段执行了最外层的函数file_lock 返回了 wrapper。 第二阶段使用 wrapper 装饰 test 第二阶段我们已经熟悉理解了。实际上 只是第一阶段是多执行的。 由于我们多给它加了一个括号 python 解释器自然会去执行该函数 该函数返回另一个装饰函数 这样就到了第二阶段。python 解释器希望我们这样去理解否则三层函数的写法很让人崩溃。后续我们继续探索装饰器能不能实现相同的功能但是能摆脱编写三层函数的噩梦。以上分析了带参数和不带参数的装饰器的区别及如何在心里去理解与接受这种写法 python 通过语法糖 函数之上的装饰器定义 代替蠢笨的手动装饰调用。 我们可以实现复杂的装饰器 但却能提供极其优雅的使用方式给调用方 还是 让人鼓舞的事实上 python的框架中大量的使用了装饰器。也说明了装饰器的强大与优雅。3.python 装饰器方法的执行时机与顺序python 是解释执行的语言我们做一个小实验以上例子先定义 log 装饰器而后再使用 log装饰器如果置换一下顺序log(say some thing) def test_dec(size length, kyNone): print execute test_dec param:%s, %s, %s % (size, length, ky) def log(infoNone): def wrapper(func): def func_dec(*args, **kwargs): r func(*args, **kwargs) print(execute done:%s % func.__name__) return r return func_dec return wrapper毫无疑问这样会报语法错误 python是 从python文件从上到下执行解释执行 只有已经定义log 才能使用它。在python 中函数是一等公民 函数也是对象在定义函数时也就是在声明一个函数对象def foo(): passdef foo()就是在声明一个函数对象 foo 即是该函数对象的引用 我们可以额外定义该对象的属性 通过dir(foo) 查看一下该函数对象有哪些属性其实是和类实例对象没有区别的以上提过 test 被 log装饰 后 test() 等同于log(test)() python 装饰器解释执行完 log def test()等同于testlog(test) 此时 test引用的函数对象是 log装饰后的函数对象log def test(): pass testlog(test)3.2 装饰器的执行顺序实际开发中我们经常会遇到使用多个装饰器如果读者理解了3.0及以上的函数对象的概念其实应能能猜出来装饰器的装饰顺序自然是从上往下执行的foo a(b(c(foo))) 但是实际的代码执行顺序是 c-b-aa b c def foo() pass以上我们使用日志装饰器和文件锁装饰器介绍了装饰器的使用并且讨论了带参数及不带参数装饰器的区别。其中三层函数的定义方式可读性非常差在下一节将重点讨论如何使用类实现装饰器简化三层装饰器的逻辑减少相似代码的编写4. 装饰器类的设计在本节中我们重点优化三层装饰器的编写除此之外笔者在实际开发中还发现了其他常见的需求例如暂存装饰器的参数。 期望通过被装饰函数找到装饰器参数 笔者在自动化测试中就使用装饰器定义测试 case 需要在 case 中配置元数据信息在实际的执行引擎部分访问该元数据信息。就是将元数据信息放到函数对象中注册被装饰函数对象。 例如某些 web 框架注册 handler 需要在装饰器中实现某些注册逻辑从以上三点出发可以看到装饰器的逻辑有某些通用的部分然而以上装饰器的例子都是通过函数实现的 但函数在内部状态 继承等方面明显不如类所以我们尝试使用类实现装饰器。并尝试实现一个通用的装饰基类4.1 思路python 提供了很多奇异方法所谓的奇异方法是指只要你实现了这个方法就可以使用 python 的某些工具方法例如实现__ len__ 方法可以使用 len() 获取长度实现__ iter__ 可以使用 iter方法返回一个迭代器其他方法还有 “__eq__”“__ne__” “__next__” 等。 其中当实现__ call__ 方法时 类可以被当做一个函数使用例如以下示例class FuncClass(object): def __call__(self): print(didiyun) F FuncClass() F() didiyun是否也可以使用 python 的这个特性实现装饰器呢?答案是可以的让我们来实现一个装饰基类 解决以上的痛点class BaseDecorator(object): def __call__(self *_, **kwargs): #1 return self.do_call(**kwargs) #2 def do_call(self, *_, **decorator_kwargs): def wrapper(func): wrapper.__explained False wraps(func) #3 def _wrap(*args, **kwargs): if not wrapper.__explained: #4 self._add_dict(func, decorator_kwargs) wrapper.__explained True return self.invoke(func, *args, **kwargs) #5 self._add_dict(_wrap, decorator_kwargs) _wrap self.wrapper(_wrap) #6 return _wrap return wrapper def wrapper(self, wrapper): return wrapper def _add_dict(self, func, decorator_kwargs): for k, v in decorator_kwargs.items(): func.__dict__[k] v def invoke(self, func, *args, **kwargs): return func(*args, **kwargs) BaseDecorator实现的并不是具体的某个装饰器逻辑,它可以作为装饰器类的基类以上我们曾分析编写装饰器通用的需求已经痛点。以下先具体讲解这个类的实现而后在讨论如何使用 1. __call__ 函数签名*_ 代表忽略变长的位置参数只接受命名参数。实际的装饰器中一般都是使用命名参数.代码可读性高 2. __call__ 本身的实现逻辑委托给了 do_call 方法主要是考虑 BaseDecorator 作为装饰基类需要提供某些工具方法及可扩展方法但是__ call__ 方法本身无法被继承所以我们退而求次将工具方法封装在自定义方法中子类还是需要重新 实现__ call__ 并调用 do_call 方法 do_call 方法的签名和__ call__ 相同 3. functools提供了 wraps 装饰器 以上我们分析过python是使用装饰后的函数对象替换之前的函数对象达到装饰的效果 可能有人会有疑问如果 之前的函数对象有一些自定义属性呢? 装饰后的新函数会不会丢掉答案是肯定的 我们可以访问之前的函数对象给其设置属性 这些属性会被存储在 对象的__ dict__ 字典中 而wraps 装饰器会把原函数的__ dict__拷贝到新的装饰后的函数对象中 因此 wraps 装饰后就不会丢掉原有的属性 而不使用则一定会丢掉。 感兴趣的读者可以点开 wraps 装饰器看一下具体实现逻辑 4. 在本节开始我们提出装饰器的通用需求其中之一是需要将装饰器的参数存放到被装饰的函数中_add_dict方法便是将装饰器参数设置到原函数以及装饰后的函数中 5. invoke 负责实现具体的装饰逻辑例如日志装饰器仅仅是打印日志那么该方法实现就是打印日志以及调用原函数。 文件锁装饰器则需要先获取锁后在执行原函数具体的装饰逻辑在该方法中实现 具体的装饰器子类应该重写该方法。下一节我们继承该BaseDecorator重写以上的日志及文件锁装饰器 6. invoke 方法是装饰函数调用时被触发的 而 wrapper 方法只会被触发一次当 python 解释器执行到log时会执行该装饰器的wrapper 方法。相当于函数被定义的时候执行了 wrapper方法在该方法内可以实现某些注册功能。将函数和某些键值映射起来放到字典中例如 web 框架的 url和handler映射 关系的注册BaseDecorator 抽出来了 invokewrapper 目的是让子类装饰器可以在这两个维度上扩展分别实现装饰及某些注册逻辑在下一节我们尝试重写日志及文件锁装饰器更直观的感受BaseDeceator 给我们带来的便利4.2 重写日志及文件锁装饰器class _log(BaseDec): def invoke(self, func, *args, **kwargs): #1 print(execute done:%s, %s % (func.__name__,func.desc) ) #2 return func(*args, **kwargs) def __call__(self, desc): return self.do_call(descdesc) log _log() #2 1. invoke方法中包括原函数以及原函数的输入参数该输入参数不是装饰器的参数信息 2. 通过 func 可以访问到装饰器中定义的 desc 参数信息 3. 创建装饰器实例 便可以像之前一样使用 log需要注意的是该装饰类变成单例 在定义装饰逻辑的时候不要轻易在 self 中储存变量通过重写日志装饰器 可以看到已经摆脱了三层函数的噩梦 成功的分离了装饰器的基本代码以及装饰逻辑代码我们可以更加聚焦于装饰逻辑的核心代码编写同时可以通过原函数访问装饰器中输入的参数例如可以访问到日志装饰器的 desc以下我们再重写文件锁装饰器class _file_lock(BaseDec): def invoke(self func, *args, **kwargs): name func.name #1 lk Lock(name, True) acquire lk.acquire() if not acquire: print(failed to acquire lock:%s,now ignore % name) return print(acquire process lock:%s % name) try: return func(*args, **kwargs) finally: lk.release() print(release process lock:%s % name) def __call__(self, name, blockTrue): return self.do_call(namename, blockblock) #2 file_lock _file_lock() #3 1. 可以通过 func 访问到装饰器中定义的 name 参数 2. 把参数传给 do_call 委托执行 3. 创建文件锁实例,其他位置就可以使用file_lock了使用新的装饰基类后 编写新的装饰器子类是非常轻松方便的事情 不需要再蹑手蹑脚的定义复杂的三层函数 不需要重复的设置装饰器参数 如果我们在项目中大量使用装饰器 不妨使用装饰基类 统一常见的功能需求。装饰器的更多用法还需要读者去发掘但是熟悉 java 的同学一定熟悉 aop 的理念 笔者深受 java 折磨多年 对 aop也几分偏爱 在我看来 python 的装饰器是 java 中的注解加 aop 的结合。下一节我们横向对比一下 java 注解与 python 装饰器的相似点 论证文章开头我们留下的一个论点5.对比 Java 的注解之所以对比 java 注解主要是笔者想从 java 的某些用法得到某些借鉴与参考 以便于我们应用到 python 中通过两种语言的对比可以让我们更深刻的理解语言设计者添加该特性的初衷以便更好的使用该特性。 更重要的是让我们面对不同语言的异同 有更大的包容性 站在欣赏的角度去对比思考对于我们快速掌握新的语言十分有益。本节绝不是为了争吵两种语言的优劣 更不想挑起语言的战争装饰器和注解最直观的相似点可能就是艾特符号了 python 使用相同的符号 对于 java 程序员是一种关照。 因为 java 程序员对于注解有一种特殊的迷恋 第三方框架就是使用眼花缭乱的注解 帮助 java 程序员实现一个个神奇的功能。而装饰器也是可以胜任的java 的注解本身只是一种元数据配置在没有注解之前 如果实现相同的元数据配置只能依赖于 xml 配置 有了注解之后我们可以把元数据配置和代码放到一起这样更加直观 也更便于修改至于某些人说 xml配置 可以省却编译打包 其实在笔者经历的项目中不论是改代码还是改配置都是需要重新走发布流程 严禁直接修改配置重启程序(除极特殊情况)。注解和注解解释器是密不可分的定义注解之后首先就应该想到如何定义解释器读取注解上的元数据配置使用该元数据配置做什么。最常见的是使用方式是使用注解注册某些组件开启某项功能例如 spring 中使用 Component注册 bean使用 RequestMapping 注册 web url 映射 junit 使用 Test 注册测试 Case Spring boot 中使用 EnableXXX 开启某些扩展功能等等注解解释器首先需要获取到Class 对象使用反射获取到注解中的元数据配置然后实现注册 开关逻辑。 以上在我们实现的解释器基类中我们也实现了类似的功能我们把装饰器的参数存放到具体的函数对象中 实际等同于注解的元数据配置 读者也可以扩展 添加一个标记 标记该函数对象确实被某装饰器装饰过。 这样便能像 java 一样轻松的实现某些注册或者开关功能。除此之外注解作为元数据配置可以作为 aop 的切面这也是注解被广泛使用的原因 注解可以配置在类属性方法之上 “注册” 功能一般是配置在类上 如果使用注解切面需要将注解配置在方法之上。以下列出使用注解 aop 可以实现的功能1. 异常拦截 在使用该注解的函数切面上将异常拦截住可以做一些通用的功能例如异常上报异常兜底异常忽略等 2. 权限控制 日志记录。 可以控制注解方法的切面的用户访问权限也可以记录用户操作 3. 自动重试 异步处理。如果我们希望异步调用某方法或者某些需要异常重试的方法可以使用注解定义切面 添加异步或重试处理注解提供了非常灵活的切面定义方式以上三种只是常见的使用方式当注解定义了切面 aop 会替换被代理的类 添加某些代理逻辑 抛开底层实现原理 实际上aop这种机制和 python 的装饰器区别并不是很大 设计模式中装饰器和代理模式本身就非常相似 以上注解可以实现的功能 python 的装饰器都是可以一一实现的。在函数被定义的时刻装饰器就已经生效了 而 aop也是通过编译期或者运行期在实际调用之前代理。python 的装饰器本身也是一个函数它通过语法糖的方式帮我们实现了装饰而 静态类型的java 选择了动态修改字节码编译器织入等更加复杂的技术实现了类似的功能。 不同的底层实现 并不能影响在使用方式及场景上互相借鉴。 所以笔者还是认为装饰器更像 java 注解 aop 的组合。 这样对比 对于java 程序可能更容易理解更好的使用装饰器。最后五阳一直在关注 AI方向我分享一个对抗AI“一本正经胡说八道”的个人技巧不要只依赖一个模型。我现在遇到拿不准的信息会把同一个问题同时扔给2-3个AI比如千问DeepSeek看它们答案的交集。这比单纯选哪个模型更靠谱。想省事的话可以用这个聚合工具一次搞定AIChatProxy https://aichatproxy.com