Python 使用描述符访问变量,而不是将此变量与实例中的目标绑定

Python 使用描述符访问变量,而不是将此变量与实例中的目标绑定,python,Python,我刚读了一本书,遇到了以下几节课: class BaseHandler(RequestHandler): @property def db(self): return self.application.db 每次我们想要访问BaseHandler实例的db属性时,就会调用db(self),返回self.application.db 与以下代码相比,此代码的优点是什么 class BaseHandler(RequestHandler): def __ini

我刚读了一本书,遇到了以下几节课:

class BaseHandler(RequestHandler):
    @property
    def db(self):
        return self.application.db
每次我们想要访问
BaseHandler
实例的
db
属性时,就会调用
db(self)
,返回
self.application.db

与以下代码相比,此代码的优点是什么

class BaseHandler(RequestHandler):
    def __init__(self):
        self.db = self.application.db
这将实例变量
db
绑定到
self.application.db

我理解前一种方法将避免我们在每个实例中使用
self.db
。另一方面,
self.application.db
具有额外的属性解析步骤(额外的


前一种方法有什么我看不到的优点吗?

它使
db
成为只读的。无法设置
base\u handler.db
,没有与属性关联的setter:

>>> class Foo(object):
...     @property
...     def bar(self): return 'spam'
... 
>>> foo = Foo()
>>> foo.bar
'spam'
>>> foo.bar = 'ham'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: can't set attribute

注意属性setter的
@name\u
decorator;property对象本身提供了一个decorator函数来创建一个新的decorator,并用新的修饰函数替换setter。还有一个
.deleter
等价物。有关更多详细信息,请参阅文档。

它使
db
成为只读。无法设置
base\u handler.db
,没有与属性关联的setter:

>>> class Foo(object):
...     @property
...     def bar(self): return 'spam'
... 
>>> foo = Foo()
>>> foo.bar
'spam'
>>> foo.bar = 'ham'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: can't set attribute

注意属性setter的
@name\u
decorator;property对象本身提供了一个decorator函数来创建一个新的decorator,并用新的修饰函数替换setter。还有一个
.deleter
等价物。有关更多详细信息,请参阅文档。

您能否举例说明如何使属性既可读取又可写入?是的,这与问题无关。谢谢。玛蒂恩,我刚才一直在考虑这个问题,并且想出了另一个原因
self.application.db
可以通过描述符访问,并且可以动态返回不同的
db
对象。由于我们不知道
应用程序的内部结构,也不知道它将来会发生什么变化,我们无法在初始化步骤中获取并保持
self.application.db
。并且应该通过描述符访问它。这个逻辑合理吗?是的,合理。存储
self.db
将存储一个静态副本,而
self.application.db
可能会更改。因此,当我们使用3d party library时,我们应该考虑这样一个事实,即属性可能开始通过描述符访问,并通过代码中的描述符访问属性。这是一个有价值的结论。我以前从来没有想过这个问题。你能举个例子说明如何使属性既能读又能写吗?是的,这与问题无关。谢谢。玛蒂恩,我刚才一直在考虑这个问题,并且想出了另一个原因
self.application.db
可以通过描述符访问,并且可以动态返回不同的
db
对象。由于我们不知道
应用程序的内部结构,也不知道它将来会发生什么变化,我们无法在初始化步骤中获取并保持
self.application.db
。并且应该通过描述符访问它。这个逻辑合理吗?是的,合理。存储
self.db
将存储一个静态副本,而
self.application.db
可能会更改。因此,当我们使用3d party library时,我们应该考虑这样一个事实,即属性可能开始通过描述符访问,并通过代码中的描述符访问属性。这是一个有价值的结论。我以前从未想过这一点。