python之装饰器的理解

· Python · 237687
python之装饰器的理解

这篇文章介绍的内容是关于python之装饰器的理解 ，有着一定的参考价值，现在分享给大家，有需要的朋友可以参考一下

1、必备

核心：函数即“变量”
定义：本质就是函数，是为了给其他函数添加附加功能
原则：
      1、不修改原函数的源代码

      2、不修改原函数的调用方式 

高阶函数+嵌套函数=>装饰器

#### 第一波 ####
def foo():
    print 'foo'
 
foo     #表示是函数
foo()   #表示执行foo函数
 
#### 第二波 ####
def foo():
    print 'foo'
 
foo = lambda x: x + 1
 
foo()   # 执行下面的lambda表达式，而不再是原来的foo函数，因为函数 foo 被重新定义了

2、需求来了

初创公司有N个业务部门，1个基础平台部门，基础平台负责提供底层的功能，如：数据库操作、redis调用、监控API等功能。业务部门使用基础功能时，只需调用基础平台提供的功能即可。如下：

############### 基础平台提供的功能如下 ###############
 
def f1():
    print 'f1'
 
def f2():
    print 'f2'
 
def f3():
    print 'f3'
 
def f4():
    print 'f4'
 
############### 业务部门A 调用基础平台提供的功能 ###############
 
f1()
f2()
f3()
f4()
 
############### 业务部门B 调用基础平台提供的功能 ###############
 
f1()
f2()
f3()
f4()

目前公司有条不紊的进行着，但是，以前基础平台的开发人员在写代码时候没有关注验证相关的问题，即：基础平台的提供的功能可以被任何人使用。现在需要对基础平台的所有功能进行重构，为平台提供的所有功能添加验证机制，即：执行功能前，先进行验证。

老大把工作交给 Low B，他是这么做的：

1

跟每个业务部门交涉，每个业务部门自己写代码，调用基础平台的功能之前先验证。诶，这样一来基础平台就不需要做任何修改了。

当天Low B 被开除了...

老大把工作交给 Low BB，他是这么做的：

1

只对基础平台的代码进行重构，让N业务部门无需做任何修改

############### 基础平台提供的功能如下 ############### def f1():    # 验证1
    # 验证2
    # 验证3
    print 'f1'def f2():    # 验证1
    # 验证2
    # 验证3
    print 'f2'def f3():    # 验证1
    # 验证2
    # 验证3
    print 'f3'def f4():    # 验证1
    # 验证2
    # 验证3
    print 'f4'############### 业务部门不变 ############### ### 业务部门A 调用基础平台提供的功能### f1()
f2()
f3()
f4()### 业务部门B 调用基础平台提供的功能 ### f1()
f2()
f3()
f4()

过了一周 Low BB 被开除了...

老大把工作交给 Low BBB，他是这么做的：

1

只对基础平台的代码进行重构，其他业务部门无需做任何修改

############### 基础平台提供的功能如下 ############### def check_login():    # 验证1
    # 验证2
    # 验证3
    passdef f1():
    
    check_login()    print 'f1'def f2():
    
    check_login()    print 'f2'def f3():
    
    check_login()    print 'f3'def f4():
    
    check_login()    
    print 'f4'

老大看了下Low BBB 的实现，嘴角漏出了一丝的欣慰的笑，语重心长的跟Low BBB聊了个天：

老大说：

写代码要遵循开发封闭原则，虽然在这个原则是用的面向对象开发，但是也适用于函数式编程，简单来说，它规定已经实现的功能代码不允许被修改，但可以被扩展，即：

  • 封闭：已实现的功能代码块

  • 开放：对扩展开发

如果将开放封闭原则应用在上述需求中，那么就不允许在函数 f1 、f2、f3、f4的内部进行修改代码，老板就给了Low BBB一个实现方案：

def w1(func):
    def inner():
        # 验证1
        # 验证2
        # 验证3
        return func()
    return inner
 
@w1
def f1():
    print 'f1'
@w1
def f2():
    print 'f2'
@w1
def f3():
    print 'f3'
@w1
def f4():
    print 'f4'

对于上述代码，也是仅仅对基础平台的代码进行修改，就可以实现在其他人调用函数 f1 f2 f3 f4 之前都进行【验证】操作，并且其他业务部门无需做任何操作。

Low BBB心惊胆战的问了下，这段代码的内部执行原理是什么呢？

老大正要生气，突然Low BBB的手机掉到地上，恰恰屏保就是Low BBB的女友照片，老大一看一紧一抖，喜笑颜开，交定了Low BBB这个朋友。详细的开始讲解了：

单独以f1为例：

def w1(func):
    def inner():
        # 验证1
        # 验证2
        # 验证3
        return func()
    return inner
 
@w1
def f1():
    print 'f1'

当写完这段代码后（函数未被执行、未被执行、未被执行），python解释器就会从上到下解释代码，步骤如下：

  1. def w1(func):  ==>将w1函数加载到内存

  2. @w1

没错，从表面上看解释器仅仅会解释这两句代码，因为函数在没有被调用之前其内部代码不会被执行。

从表面上看解释器着实会执行这两句，但是 @w1 这一句代码里却有大文章，@函数名 是python的一种语法糖。

如上例@w1内部会执行一下操作：

  • 执行w1函数，并将 @w1 下面的 函数 作为w1函数的参数，即：@w1 等价于 w1(f1)
    所以，内部就会去执行：
        def inner:
            #验证
            return f1()   # func是参数，此时 func 等于 f1
        return inner     # 返回的 inner，inner代表的是函数，非执行函数
    其实就是将原来的 f1 函数塞进另外一个函数中

  • 将执行完的 w1 函数返回值赋值给@w1下面的函数的函数名
    w1函数的返回值是：
       def inner:
            #验证
            return 原来f1()  # 此处的 f1 表示原来的f1函数
    然后，将此返回值再重新赋值给 f1，即：
    新f1 = def inner:
                #验证
                return 原来f1() 
    所以，以后业务部门想要执行 f1 函数时，就会执行 新f1 函数，在 新f1 函数内部先执行验证，再执行原来的f1函数，然后将 原来f1 函数的返回值 返回给了业务调用者。
    如此一来， 即执行了验证的功能，又执行了原来f1函数的内容，并将原f1函数返回值 返回给业务调用着

Low BBB 你明白了吗？要是没明白的话，我晚上去你家帮你解决吧！！！

先把上述流程看懂，之后还会继续更新...

3、问答时间

问题：被装饰的函数如果有参数呢？

def w1(func):    def inner(arg):        # 验证1
        # 验证2
        # 验证3
        return func(arg)    return inner

@w1def f1(arg):    print 'f1'

def w1(func):    def inner(arg1,arg2):        # 验证1
        # 验证2
        # 验证3
        return func(arg1,arg2)    return inner

@w1def f1(arg1,arg2):    print 'f1'

def w1(func):    def inner(arg1,arg2,arg3):        # 验证1
        # 验证2
        # 验证3
        return func(arg1,arg2,arg3)    return inner

@w1def f1(arg1,arg2,arg3):    print 'f1'

问题：可以装饰具有处理n个参数的函数的装饰器？

def w1(func):
    def inner(*args,**kwargs):
        # 验证1
        # 验证2
        # 验证3
        return func(*args,**kwargs)
    return inner
 
@w1
def f1(arg1,arg2,arg3):
    print 'f1'

问题：一个函数可以被多个装饰器装饰吗？

def w1(func):
    def inner(*args,**kwargs):
        # 验证1
        # 验证2
        # 验证3
        return func(*args,**kwargs)
    return inner
 
def w2(func):
    def inner(*args,**kwargs):
        # 验证1
        # 验证2
        # 验证3
        return func(*args,**kwargs)
    return inner
 
 
@w1
@w2
def f1(arg1,arg2,arg3):
    print 'f1'

问题：还有什么更吊的装饰器吗？

#!/usr/bin/env python
#coding:utf-8
  
def Before(request,kargs):
    print 'before'
      
def After(request,kargs):
    print 'after'
  
  
def Filter(before_func,after_func):
    def outer(main_func):
        def wrapper(request,kargs):
              
            before_result = before_func(request,kargs)
            if(before_result != None):
                return before_result;
              
            main_result = main_func(request,kargs)
            if(main_result != None):
                return main_result;
              
            after_result = after_func(request,kargs)
            if(after_result != None):
                return after_result;
              
        return wrapper
    return outer
      
@Filter(Before, After)
def Index(request,kargs):
    print 'index'

4、functools.wraps

上述的装饰器虽然已经完成了其应有的功能，即：装饰器内的函数代指了原函数，注意其只是代指而非相等，原函数的元信息没有被赋值到装饰器函数内部。例如：函数的注释信息

def outer(func):    def inner(*args, **kwargs):        print(inner.__doc__)  # None
        return func()    return inner

@outerdef function():    """
    asdfasd
    :return:    """
    print('func')

如果使用@functools.wraps装饰装饰器内的函数，那么就会代指元信息和函数。

def outer(func):
    @functools.wraps(func)    def inner(*args, **kwargs):        print(inner.__doc__)  # None
        return func()    return inner

@outerdef function():    """
    asdfasd
    :return:    """
    print('func')

以上就是python之装饰器的理解的详细内容，更多请关注昆居客【www.kunjuke.com】。

相关推荐：

GitHub Copilot底层原理解读：深入理解大模型如何理解你的代码

GitHub Copilot代码建议偏差源于上下文窗口建模、注释-代码对齐微调、语言语法感知、跨文件依赖推理及脱敏过滤五方面限制，需针对性优化配置与提示方式。 ☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜ 如果您在使用GitHub Copilot时发现其建议代码与当前上下文存在语义偏差，或无法准确响应注释意图，则可能是由于模型对局部代码结构...

CodeBuddy的上下文理解能力强吗？能理解整个文件吗？

应启用全文件AST解析、多文件关联、项目结构扫描及清除缓存四项操作：一、切换Context Mode为Full File AST Parsing；二、Ctrl/Command多选文件后右键“Send to CodeBuddy Context”；三、执行“CodeBuddy: Scan Project Structure”命令；四、在设置中清除context cache并重启。 ☞☞☞AI 智能聊天...
· AI · 100176

千问支持多模态输入吗？图文混合理解

需确认千问版本是否支持多模态：仅含“VL”等标识的模型（如Qwen3.5-9B）具备图文理解能力；须检查API文档、界面图标、测试响应，并确保接口格式正确、视觉组件启用、UI开放上传、图像预处理合规。 如果您在使用千问模型时希望同时输入图片和文字以获得更精准的理解与响应，则需要确认所用的具体千问版本是否具备视觉语言能力。以下是针对该问题的多种验证与使用方式： 一、确认模型版本是否支持多模态 千问系...
· AI · 11982

CodeBuddy的AI能理解MyBatis的XML映射文件吗？

CodeBuddy 解析 MyBatis XML 不准确时，需确保XML纳入工程上下文、显式声明namespace与resultMap、提供Java接口和XML片段作为对话锚点、启用Craft智能体校验、使用CLI离线验证绑定有效性。 ☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜ 如果您在使用 CodeBuddy 辅助开发 MyBatis ...
· AI · 232384

智谱清影和Google的Veo2在视频质量和物理世界理解方面的差距到底有多大？

Veo 2在视频质量与物理世界理解上全面领先智谱清影：原生4K/60fps vs 1080p/30fps；物理建模更符合重力、流体、碰撞规律；镜头控制支持dolly zoom等专业运镜；微表情建模精准匹配FACS生理时序。 ☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜ 如果将智谱清影与Google Veo 2在视频质量与物理世界理解能力上进...

CodeBuddy怎么理解整个Git仓库的项目结构？

CodeBuddy需显式触发仓库结构索引、指定根目录与配置、启用Git元数据感知、注入自定义结构描述文件及强制刷新缓存，才能准确理解全仓库项目结构。 ☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜ 如果您在使用CodeBuddy时发现其对项目逻辑的理解不够准确或上下文感知薄弱，可能是因为它尚未完整加载和解析整个Git仓库的目录结构与依赖关系。...
· AI · 29590

豆包AI怎么解释代码_豆包AI代码理解方法【教程】

若豆包AI对无注释代码解释不清，应采用五类方法：一、结构化注释指令；二、提问式引导解释；三、上下文感知分段提交；四、运行错误反向推导；五、特征关键词触发深度解释。 ☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜ 如果您将一段无注释或逻辑模糊的代码提交给豆包AI，但返回结果中关键变量用途不明、控制流走向不清或函数职责不明确，则可能是由于提示词缺...
· AI · 11106

千问在处理方言和网络用语时的理解能力怎么样？

应启用Qwen3-ASR-1.7B语音识别模块、Qwen3-VL-Reranker-8B重排序引擎、Thinking混合推理引擎、Qwen3-Reranker-0.6B语义校准层及异构MoE方言专家模块，分步验证并提升对方言及网络用语的理解能力。 ☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜ 如果您尝试让千问模型理解带有地域特征或网络文化色...
· AI · 295706