python – 在类“主要缺陷”中实现装饰器？

2019年8月4日 163次阅读

为什么这个装饰策略被认为是坏的？ (..或者是它！？)

class User(object):

    def __init__(self):
        self.thing = 5

    def __atomic_rate_change(fn):
        def wrapper(self,*args,**kwargs):
            print "start magic"
            self.thing += 1
            fn(self,*args,**kwargs)
            print "end magic"
        return wrapper

    @__atomic_rate_change
    def foo(self,add):
        print self.__atomic_rate_change # <bound method User.__atomic_rate_change of <__main__.User object at 0x6ffffe1ef50>>
        self.thing += add
        print "normal call {0}".format(self.thing)

test = User()
test.foo(1)

这有效.但是,根据下面的资源,这是不好的做法.理由是：

[…] there is major flaw in this approach: atomic_rating_change becomes an
instance method of the User class. That doesn’t make any sense. More
than this, it doesn’t even work as a method: if you call it, the
decorated parameter will be used as self.

https://medium.com/@vadimpushtaev/decorator-inside-python-class-1e74d23107f6

我不明白为什么atomic_rate_change是一个实例方法是一个问题/错误/错误.我只是打算在类中使用装饰器.也许在这种情况下它没关系？

最佳答案 在风格上,将函数定义放入不是方法的类定义中是不合适的(甚至可以是unpythonic).
Flat is better than nested,所以在类之外声明函数可能更好.这样当读者看到你的类时,就不会混淆为什么有一个方法不会将self作为参数(因为当它只是一个装饰器时,函数被声明为一个方法,尽管这个如果函数是@staticmethod,则略有不同.

如果您担心它在类之外使用,请在前面添加_然后从my_package导入*将不会导入它.它仍然可以在该模块中使用,但除非明确导入,否则不会在外部使用.

实际上,作者指的是范围的偶然奇怪的行为(类似于Javascript中关于是否使用function(){…或()=> {…的辩论,基于事物的范围.)如果你不小心,不小心在装饰者的错误部分有自己的逻辑,你可能会有范围问题.

我可以看到在类中使用函数的唯一优点可能是因为它更接近于方法(但是引入了不必要的嵌套,潜在的作用域问题,以及认识到装饰器而不是方法的认知负荷),以及更好的隐藏该函数的名称以_或__开头.

TL; DR文体/ Pythonicity问题,以及潜在的范围问题.

点赞