Pykka 与 @属性设置器的行为

Question

我正在玩 pykka 的演员模型，发现了一些有趣的行为。这是

的演示

启动一个 actor
获取它的代理
设置其@properties 之一

代码如下：

import time
import pykka

from sys import version_info as python_version
if python_version > (3, 0):
    from _thread import get_ident
else:
    from thread import get_ident

startTime = time.time()

def debug(msg, prefix='MSG'):
    msgProc = "%s (thread #%s @ t = %.2fs): %s" % (prefix,get_ident(), time.time() - startTime, msg)
    print(msgProc)

def mainThread():

    debug('Launching support actor...', prefix='MAIN')
    supportRef = supportThread.start()

    debug('Getting support proxy...', prefix='MAIN')
    supportProxy = supportRef.proxy()

    debug('Getting myVal obj...', prefix='MAIN')
    obj = supportProxy.myVal
    debug(obj, prefix='MAIN')

    debug('Setting myVal obj...', prefix='MAIN')
    supportProxy.myVal = 2

    debug('Setting myVal obj...', prefix='MAIN')
    supportProxy.myVal = 3

    supportProxy.stop()


class supportThread(pykka.ThreadingActor):

    def __init__(self):
        super(supportThread, self).__init__()

        self._myVal = 0

    @property
    def myVal(self):
       debug("Getting value", prefix='SUPPORT')
       return self._myVal

    @myVal.setter
    def myVal(self, value):

       debug("Setting value: processing for 1s...", prefix='SUPPORT')
       time.sleep(1)

       debug("Setting value: done", prefix='SUPPORT')
       self._myVal = value

mainThread()

输出如下所示：

MAIN (thread #16344 @ t = 0.00s): Launching support actor...
MAIN (thread #16344 @ t = 0.00s): Getting support proxy...
SUPPORT (thread #16344 @ t = 0.00s): Getting value
MAIN (thread #16344 @ t = 0.00s): Getting myVal obj...
MAIN (thread #16344 @ t = 0.00s): <pykka.threading.ThreadingFuture object at 0x0000000002998518>
MAIN (thread #16344 @ t = 0.00s): Setting myVal obj...
SUPPORT (thread #16248 @ t = 0.00s): Getting value
SUPPORT (thread #16248 @ t = 0.00s): Setting value: processing for 1s...
SUPPORT (thread #16248 @ t = 1.00s): Setting value: done
MAIN (thread #16344 @ t = 1.00s): Setting myVal obj...
SUPPORT (thread #16248 @ t = 1.01s): Setting value: processing for 1s...
SUPPORT (thread #16248 @ t = 2.01s): Setting value: done
[Finished in 2.3s]

我有几个问题。

为什么 getter supportThread.myVal() 在调用 .proxy() 时在主线程的上下文中被调用？
为什么 supportProxy.myVal = <a new value> 行导致主线程等待 actor 完成？

这对我来说似乎是一个错误：我认为只有在 ThreadingFuture 上调用 .get() 时代理才应该阻止执行。或者这是故意的？

Answer 1

免责声明：我是 Pykka 的作者。

旁白：Pykka 并没有死，它只是为它的目的工作得很好：为 Mopidy music server 及其 100 多个扩展提供并发抽象。

Pykka 的属性行为不是最佳的，但这是有原因的。

要创建代理对象 Pykka 必须内省目标对象的 API。当测试目标对象上可用的属性是可调用对象、属性还是 "traversible attributes" 时，对每个属性调用一次 getattr()。这会导致属性 getter 被调用。见 Proxy._get_attributes() and Actor._get_attribute_from_path() .
因为在 Python 中无法从属性 setter 中获取 return 值，属性设置Pykka 代理采用等待 setter 完成的安全默认值，以便 setter 中引发的任何异常都可以在 mainThread() 中的调用站点上重新引发。另一种方法是不处理属性 setter 引发的任何异常。有关详细信息，请参阅 Proxy.__setattr__()。

总而言之，Pykka 的属性 "works"，但您可以通过使用方法调用获得更多控制权，因为这样您总能得到未来并可以自行决定是否需要等待结果。

无论您是否使用 Pykka，我发现最好不要在属性 getter 中做任何昂贵的工作，而是使用适当的方法来做 "expensive" 工作.

API 设计直接影响您的用户如何使用 API:

具有属性的对象会重复使用相同的属性，从而重复重新计算。保持财产简单和便宜。
公开方法 return 结果的对象通常会导致调用者将结果保存在变量中并重复使用相同的结果，而不是多次调用该方法。将方法用于任何重要的工作。如果它真的很昂贵，请考虑除 get_ 之外的另一个前缀，例如 load_、fetch_ 或 calculate_，进一步表明用户应该对结果保持句柄，并且重复使用它。

为了自己遵循这些原则，很久以前，Mopidy 的核心 API 从使用大量属性迁移到使用 getters 和 setters。在下一个主要版本中，所有属性将从 Mopidy 的核心中删除 API。由于代理创建的工作方式，此清理将大大减少 Mopidy 的启动时间。

Pykka 与 @属性 设置器的行为

Pykka's behaviour with @property setters

python

pykka

Pykka 与 @属性设置器的行为