我有一个问题的可变'保险模式'的转让装饰。我将通过下面的decorator语句来完成:
@execute_complete_reservation(True)
def test_booking_gta_object(self):
self.test_select_gta_object()
但不幸的是,这种说法行不通。也许有更好的方法来解决这个问题。
def execute_complete_reservation(test_case,insurance_mode):
def inner_function(self,*args,**kwargs):
self.test_create_qsf_query()
test_case(self,*args,**kwargs)
self.test_select_room_option()
if insurance_mode:
self.test_accept_insurance_crosseling()
else:
self.test_decline_insurance_crosseling()
self.test_configure_pax_details()
self.test_configure_payer_details
return inner_function
带参数的decorators的语法有点不同-带参数的decorator应该返回一个函数,该函数将接受一个函数并返回另一个函数。所以它应该返回一个普通的装饰器。有点困惑,对吧?我的意思是:
Here您可以阅读有关此主题的更多信息-也可以使用可调用对象实现此功能,这里也将对此进行说明。
我想展示一个非常优雅的主意。dubrownik提出的解决方案显示了一个始终相同的模式:不管decorator做什么,都需要三层包装。
所以我认为这是一个元装饰器的工作,也就是装饰器的装饰器。由于decorator是一个函数,它实际上是一个带参数的常规decorator:
为了添加参数,这可以应用于常规的装饰器。例如,假设我们有一个decorator,它将函数的结果加倍:
使用
@parametrized
我们可以构建具有参数的泛型@multiply
装饰器通常,参数化装饰器的第一个参数是函数,而其余的参数将与参数化装饰器的参数相对应。
一个有趣的用法示例可以是类型安全的断言装饰器:
最后一点:这里我不使用
functools.wraps
作为包装函数,但我建议您一直使用它。编辑:要深入了解decorators的心理模型,请看一下this很棒的Pycon对话。很值得花30分钟。
考虑带参数的装饰器的一种方法是
翻译成
所以如果装潢师有争论
翻译成
decorator_with_args
是一个接受自定义参数并返回实际装饰器(将应用于装饰函数)的函数。我用了一个简单的技巧来简化我的装饰
更新:
在上面,
foo
变成real_decorator(foo)
修饰函数的一个效果是在decorator声明时重写名称
foo
。foo
被real_decorator
返回的任何内容“重写”。在本例中,是一个新的函数对象。所有
foo
的元数据都被重写,特别是docstring和函数名。functools.wraps为我们提供了一个方便的方法来“提升”docstring和返回函数的名称。
相关问题 更多 >
编程相关推荐