Pythondelattr避免无限递归技巧

大家好，我们又见面了啊~本文《使用 delattr 时，若直接调用 delattr(obj, name)，可能会在某些情况下引发无限递归，例如在 __delattr__ 方法中又调用 delattr，而没有正确处理。为了避免无限递归，可以采用以下方式：✅ 正确写法（避免无限递归）：class MyClass: def __delattr__(self, name): if hasattr(self, name): # 使用 object 的 __delattr__ 方法，避免递归 object.__delattr__(self, name) else: raise AttributeError(f"'{self.__class__.__name__}' has no attribute '{name}'")🔍 原理说明：object.__delattr__(self, name) 是 Python 内置的 __delattr__ 实现，它不会触发你自定义的 __delattr__ 方法。如果你直接调用 delattr(self, name)，就会再次进入你自己的 __delattr__，从而导致无限递归。🚫 错误写法（可能导致无限递归）：def __delattr__(self, name): delattr(self, name) # 会再次调用 __delattr__，导致无限递归✅ 推荐做法总结：在自定义 `》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

直接在 __delattr__ 中调用 delattr(self, name) 会导致无限递归并触发 RecursionError；正确做法是显式调用 object.__delattr__(self, name) 绕过自定义逻辑。

delattr 触发 __delattr__ 时的递归陷阱

直接在 __delattr__ 方法里调用 delattr(self, name) 会导致无限递归——因为 delattr 内部会再次触发 __delattr__，形成死循环。常见报错是 RecursionError: maximum recursion depth exceeded。

绕过自定义 __delattr__ 的标准写法

必须跳过当前类的 __delattr__，委托给父类（通常是 object）的实现。正确方式是：

def __delattr__(self, name):
    if name == 'some_special_attr':
        # 自定义逻辑，比如清理资源
        pass
    # 关键：用 object.__delattr__ 绕过自身
    object.__delattr__(self, name)

• 永远不要在 __delattr__ 里调用 delattr(self, name) 或 self.__delattr__(name)
• 显式调用 object.__delattr__(self, name) 是最安全、最明确的绕过方式
• 如果继承链中有中间类也重写了 __delattr__，且你希望跳过它，仍应直接调用 object.__delattr__，而非 super().__delattr__(name)（后者可能又落入递归）

需要拦截并有条件删除的典型场景

比如实现只读属性控制、动态代理、或属性访问审计时，需判断是否允许删除：

class ControlledAttrs:
    def __init__(self):
        self._locked = False
def lock(self):
    self._locked = True

def __delattr__(self, name):
    if name == '_locked':
        object.__delattr__(self, name)
        return
    if self._locked and not name.startswith('_'):
        raise AttributeError(f"Cannot delete '{name}' in locked state")
    object.__delattr__(self, name)

• 对特殊内部属性（如 _locked）应优先处理，避免误判
• 条件判断必须放在 object.__delattr__ 调用之前，否则无法拦截
• 注意属性名匹配逻辑：用 name.startswith('_') 比硬编码列表更灵活，但也更易漏判

getattr + delattr 组合使用时的隐性风险

有人想先检查属性是否存在再决定是否删除，写出类似 if hasattr(self, name): delattr(self, name)，这在重写 __delattr__ 时极易出错：

• hasattr 底层调用 getattr，不触发 __delattr__，看似安全
• 但紧接的 delattr 仍会触发你的 __delattr__，若其中又调用了 hasattr 或 getattr（比如做存在性校验），就可能间接引发递归
• 更稳妥的做法是：所有存在性判断都基于 self.__dict__ 或 vars(self)（仅对实例属性有效），避开描述符和 __getattribute__ 干扰

真正棘手的地方在于：递归不一定立刻暴露，它可能藏在嵌套的属性清理逻辑里，等对象销毁或 GC 时才爆发。

今天关于《Pythondelattr避免无限递归技巧》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！