现在,我了解你的设计,你会发现一切都是错误的。
首先,Outer是一类;它没有得到__call__
版。你的第17行正要构造一个空的Outer
对象,并且什么也不做。如果你想“呼叫”对象,你可以定义一个__init__
方法,或者,正如Sheena所建议的那样,定义一个__new__
并拦截初始化,因为你实际上并不需要初始化对象。
老实说,我不认为有人不明白__call__
是如何工作的,但应该尝试构建一些棘手的问题。但如果你坚持,请继续阅读。
这是一个非常奇怪的,也许是坏的设计,收集这种类的东西在类而不是一个实例。请记住,类变量实际上是全局变量,包含所有这些变量。如果你尝试使用Outer
或者从多个线程/事件处理程序/ greenlet /无论如何,这些使用将最终彼此跺脚。即使你认为现在不会成为问题,它可能会在未来某个时候。
您可以创建一个Outer
实例,并将其成员用作装饰器。例如:
from outer_library import Outer
outer = Outer()
@outer.get("/")
…
但我不确定那会好很多。这里的整个设计似乎涉及在模块级别执行操作,即使看起来您只是定义普通函数并在最后调用函数。你设法混淆自己的事实应该是这种设计有多混淆的证据。
但如果你做想要做到这一点,你可能想要做的是定义Outer.__init__
方法内的类,并将它们分配给实例成员。类是一流的值,可以像任何其他值一样分配给变量。然后,使用这些类的__init__
(或__new__
)方法来完成你想要的工作,使这些类模拟函数。
这似乎令人困惑或误导。但请记住,你所要做的全部事情就是以一种看起来像一种方法的方式使用一个类,这样就会产生这种混淆。但是,如果你愿意,你可以编写装饰器作为函数(在这种情况下,作为Outer
的常规实例方法);它只是使问题的一个不同部分,而不是这部分。
设计类似这样东西的一种更常见的方式是使Outer
成为一个完全正常的类,人们可以创建子类或创建实例,并提供一种明确的非奇妙方式来将处理函数方法或函数附加到URL。然后,一旦工作,设计一种方法来简化处理程序注册与装饰器。
为什么要使用一个嵌套类*在所有*? –
因此,我试图让Outer类包含将接受参数的装饰器,最好的方法是将装饰器写成类http://stackoverflow.com/questions/10610824/python-shortcut-for-writing- decorator-which-accept-arguments – sri
是的,使用装饰器的类是一个好主意,但这并不意味着你需要使用* nested *类。你想要解决什么问题? –