方法1：基本注册装饰器
我已经在这里回答了这个问题：在Python中通过数组索引调用函数=）
方法2：源代码解析
如果您无法控制类定义（它是您想要的假设的一种解释），则这是不可能的（没有代码的读取-反射），因为装饰器可以是无操作的装饰器（例如在我的链接示例中）仅返回未修改的函数。（但是，如果您允许自己包装/重新定义装饰器，请参见方法3：将装饰器转换为“具有自我意识”，那么您将找到一个优雅的解决方案）
这是一个可怕的骇客，但是您可以使用该inspect模块读取源代码本身并进行解析。这在交互式解释器中将不起作用，因为检查模块将拒绝以交互方式提供源代码。但是，以下是概念证明。
import inspect
def deco(func):
return func
def deco2():
def wrapper(func):
pass
return wrapper
class Test(object):
@deco
def method(self):
pass
@deco2()
def method2(self):
pass
def methodsWithDecorator(cls, decoratorName):
sourcelines = inspect.getsourcelines(cls)[0]
for i,line in enumerate(sourcelines):
line = line.strip()
if line.split('(')[0].strip() == '@'+decoratorName:
nextLine = sourcelines[i+1]
name = nextLine.split('def')[1].split('(')[0].strip()
yield(name)
有用！：
>>> print(list( methodsWithDecorator(Test, 'deco') ))
['method']
请注意，必须注意解析和python语法，例如@deco和@deco(...是有效结果，但@deco2如果仅要求则不应返回'deco'。我们注意到，根据http://docs.python.org/reference/compound_stmts.html上的官方python语法，装饰器如下：
decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE
不必处理诸如此类的案件，我们松了一口气@(deco)。但请注意，这仍然没有真正帮助你，如果你真的很复杂的装饰，例如@getDecorator(...)，如
def getDecorator():
return deco
因此，这种分析代码的“尽力而为”策略无法检测到这种情况。尽管如果您正在使用此方法，那么您真正想要的是定义中该方法顶部的内容，在本例中为getDecorator。
根据规范，@foo1.bar2.baz3(...)作为装饰者也是有效的。您可以扩展此方法以进行处理。您也可以<function object ...>花费很多精力来扩展此方法以返回a而不是函数的名称。但是，这种方法是骇人听闻的，而且很糟糕。
方法3：将装饰器转换为“自我意识”
如果您无法控制装饰器定义（这是您想要的另一种解释），那么所有这些问题都会消失，因为您可以控制装饰器的应用方式。因此，您可以通过包装装饰器来修改装饰器，以创建自己的装饰器，并使用该装饰器装饰功能。让我再说一遍：您可以创建一个装饰器来装饰您无法控制的装饰器，“启发”它，在我们的例子中，这使其可以像以前那样做，还可以将.decorator元数据属性附加到它返回的可调用对象上，让您跟踪“此功能是否经过装饰？让我们检查function.decorator！”。您可以遍历类的方法，然后检查装饰器是否具有适当的.decorator属性！=）如此处所示：
def makeRegisteringDecorator(foreignDecorator):
"""
Returns a copy of foreignDecorator, which is identical in every
way(*), except also appends a .decorator property to the callable it
spits out.
"""
def newDecorator(func):
R = foreignDecorator(func)
R.decorator = newDecorator
return R
newDecorator.__name__ = foreignDecorator.__name__
newDecorator.__doc__ = foreignDecorator.__doc__
return newDecorator
示范@decorator：
deco = makeRegisteringDecorator(deco)
class Test2(object):
@deco
def method(self):
pass
@deco2()
def method2(self):
pass
def methodsWithDecorator(cls, decorator):
"""
Returns all methods in CLS with DECORATOR as the
outermost decorator.
DECORATOR must be a "registering decorator"; one
can make any decorator "registering" via the
makeRegisteringDecorator function.
"""
for maybeDecorated in cls.__dict__.values():
if hasattr(maybeDecorated, 'decorator'):
if maybeDecorated.decorator == decorator:
print(maybeDecorated)
yield maybeDecorated
有用！：
>>> print(list( methodsWithDecorator(Test2, deco) ))
[<function method at 0x7d62f8>]
但是，“注册装饰器”必须是最外面的装饰器，否则.decorator属性注释将丢失。例如在火车上
@decoOutermost
@deco
@decoInnermost
def func(): ...
您只能看到decoOutermost公开的元数据，除非我们保留对“更内部”包装器的引用。
旁注：以上方法还可以构建一个.decorator，以跟踪整个已应用装饰器和输入函数以及装饰器工厂参数的堆栈。=）例如，如果考虑注释掉的行R.original = func，则使用这样的方法来跟踪所有包装层是可行的。如果我编写装饰器库，这是我个人要做的事情，因为它允许深入的自省。
@foo和之间也有区别@bar(...)。虽然它们都是规范中定义的“装饰器表达”，但请注意，这foo是一个装饰器，同时会bar(...)返回动态创建的装饰器，然后将其应用。因此，您需要一个单独的函数makeRegisteringDecoratorFactory，该函数有点像，makeRegisteringDecorator但甚至需要更多信息：
def makeRegisteringDecoratorFactory(foreignDecoratorFactory):
def newDecoratorFactory(*args, **kw):
oldGeneratedDecorator = foreignDecoratorFactory(*args, **kw)
def newGeneratedDecorator(func):
modifiedFunc = oldGeneratedDecorator(func)
modifiedFunc.decorator = newDecoratorFactory
return modifiedFunc
return newGeneratedDecorator
newDecoratorFactory.__name__ = foreignDecoratorFactory.__name__
newDecoratorFactory.__doc__ = foreignDecoratorFactory.__doc__
return newDecoratorFactory
示范@decorator(...)：
def deco2():
def simpleDeco(func):
return func
return simpleDeco
deco2 = makeRegisteringDecoratorFactory(deco2)
print(deco2.__name__)
@deco2()
def f():
pass
此生成器工厂包装器也可以工作：
>>> print(f.decorator)
<function deco2 at 0x6a6408>
奖金，让我们甚至尝试方法＃3如下：
def getDecorator():
return deco
class Test3(object):
@getDecorator()
def method(self):
pass
@deco2()
def method2(self):
pass
结果：
>>> print(list( methodsWithDecorator(Test3, deco) ))
[<function method at 0x7d62f8>]
如您所见，与method2不同，@ deco可以正确识别，即使它从未在类中明确编写。与method2不同，如果方法是在运行时添加（手动，通过元类等）或继承的，则此方法也将起作用。
请注意，您还可以装饰一个类，因此，如果您“启发”用于装饰方法和类的装饰器，然后在要分析的类的主体内编写一个类，methodsWithDecorator则将装饰后的类返回为以及装饰方法。可以认为这是一项功能，但是您可以通过检查装饰器的参数来轻松编写逻辑以忽略那些逻辑，即.original实现所需的语义。