如何获取给定类 A 的所有方法,这些方法用 @decorator2
?
class A():
def method_a(self):
pass
@decorator1
def method_b(self, b):
pass
@decorator2
def method_c(self, t=5):
pass
原文由 kraiz 发布,翻译遵循 CC BY-SA 4.0 许可协议
扩展@ninjagecko在方法2:源代码解析中的优秀答案,您可以使用Python 2.6中引入的 ast
模块来执行自检,只要inspect模块可以访问源代码。
def findDecorators(target):
import ast, inspect
res = {}
def visit_FunctionDef(node):
res[node.name] = [ast.dump(e) for e in node.decorator_list]
V = ast.NodeVisitor()
V.visit_FunctionDef = visit_FunctionDef
V.visit(compile(inspect.getsource(target), '?', 'exec', ast.PyCF_ONLY_AST))
return res
我添加了一个稍微复杂的装饰方法:
@x.y.decorator2
def method_d(self, t=5): pass
结果:
> findDecorators(A)
{'method_a': [],
'method_b': ["Name(id='decorator1', ctx=Load())"],
'method_c': ["Name(id='decorator2', ctx=Load())"],
'method_d': ["Attribute(value=Attribute(value=Name(id='x', ctx=Load()), attr='y', ctx=Load()), attr='decorator2', ctx=Load())"]}
原文由 Shane Holloway 发布,翻译遵循 CC BY-SA 3.0 许可协议
2 回答5.3k 阅读✓ 已解决
2 回答1.2k 阅读✓ 已解决
4 回答1.5k 阅读✓ 已解决
3 回答1.4k 阅读✓ 已解决
3 回答1.3k 阅读✓ 已解决
2 回答957 阅读✓ 已解决
1 回答1.8k 阅读✓ 已解决
方法一:基础注册装饰器
我已经在这里回答了这个问题: Calling functions by array index in Python =)
方法二:源码解析
如果您无法控制 class definition ,这是对您想要假设的一种解释,这是 不可能 的(没有代码阅读反射),因为例如装饰器可能是无操作装饰器(如在我的链接示例中)仅返回未修改的函数。 (尽管如此,如果您允许自己包装/重新定义装饰器,请参阅 方法 3:将装饰器转换为“自我感知” ,那么您将找到一个优雅的解决方案)
这是一个可怕的黑客攻击,但您可以使用
inspect
模块来读取源代码本身并解析它。这在交互式解释器中不起作用,因为 inspect 模块将拒绝在交互模式下提供源代码。然而,下面是一个概念证明。有用!:
请注意,必须注意解析和 python 语法,例如
@deco
和@deco(...
是有效结果,但是@deco2
--- 是有效的结果,但是 —对于'deco'
。我们注意到,根据 http://docs.python.org/reference/compound_stmts.html 的官方 python 语法,装饰器如下所示:我们松了一口气,因为不必处理像
@(deco)
这样的情况。但是请注意,如果您有非常复杂的装饰器,例如@getDecorator(...)
,这仍然对您没有真正的帮助,例如因此,这种尽力而为的代码解析策略无法检测到此类情况。尽管如果您使用此方法,您真正想要的是定义中方法之上的内容,在本例中为
getDecorator
。根据规范,将
@foo1.bar2.baz3(...)
作为装饰器也是有效的。您可以扩展此方法以使用它。您也可以扩展此方法以返回<function object ...>
而不是函数的名称,这需要付出很多努力。然而,这种方法是骇人听闻的和可怕的。方法 3:将装饰器转换为“自我意识”
_如果您无法控制 装饰器 定义_(这是您想要的另一种解释),那么所有这些问题都会消失,因为您可以控制装饰器的应用方式。因此,您可以通过 包装 来修改装饰器,创建您 自己的 装饰器,并使用 它 来装饰您的函数。让我再说一遍:你可以制作一个装饰器来装饰你无法控制的装饰器,“启发”它,在我们的例子中,这让它做它以前做的事情,但 也 附加了一个
.decorator
它返回的可调用对象的元数据属性,允许您跟踪“这个函数是否被装饰?让我们检查一下 function.decorator!”。 然后 您可以迭代类的方法,并检查装饰器是否具有适当的.decorator
属性! =) 如此处所示:@decorator
的演示:有用!:
但是,“注册装饰器”必须是 最外层的装饰器,否则
.decorator
属性注解会丢失。例如在一列火车中您只能看到
decoOutermost
公开的元数据,除非我们保留对“更多内部”包装器的引用。旁注:上述方法还可以构建一个
.decorator
跟踪 应用装饰器和输入函数以及装饰器工厂参数的整个堆栈。 =) 例如,如果您考虑注释掉的行R.original = func
,使用这样的方法来跟踪所有包装层是可行的。如果我编写装饰器库,这就是我个人会做的事情,因为它允许进行深入的自省。@foo
和@bar(...)
之间也有区别。虽然它们都是规范中定义的“装饰器表达式”,但请注意foo
是一个装饰器,而bar(...)
返回一个动态创建的装饰器,然后应用它。因此,您需要一个单独的函数makeRegisteringDecoratorFactory
,有点像makeRegisteringDecorator
但更多元:@decorator(...)
的演示:这个生成器工厂包装器也可以工作:
奖金 让我们甚至尝试使用方法#3进行以下操作:
结果:
正如您所看到的,与 method2 不同,@deco 被正确识别,即使它从未明确写入类中。与 method2 不同,如果方法是在运行时添加(手动、通过元类等)或继承的,这也将起作用。
请注意,您还可以装饰一个类,因此如果您“启发”一个用于装饰方法和类的装饰器,然后 在您要分析的类的主体中 编写一个类,那么
methodsWithDecorator
将返回装饰类和装饰方法。人们可以认为这是一项功能,但您可以通过检查装饰器的参数(即.original
)轻松编写逻辑来忽略这些功能,以实现所需的语义。