Though I'm pretty much entirely against apis of this sort:
- because they're imo entirely superfluous and use classes unnecessarily, and
- because they're enforcing behind-the-scenes object setup and persistence (that definitely isn't required to get actor behavior) which you don't really need for holding long running state if running
trio task functions in separate thread sessions, communicating over our channels,
- because most of these systems rely on the futures/promises paradigm which
trio explicitly avoids and thus most of why you would want a method-as-callback api is moot,
but, it seems users coming from the actor systems space are confused when they don't see apis of this sort.
Thus, I propose we at least have a (couple) recipe(s) to show how such things can be accomplished.
#190 is one effort on this front for @fjarri.
Some examples from the mentioned projects:
ray's actors are basically just classes instantiated and persisted in a thread - further I would argue these aren't real actors as in the actor model (they can't spawn other actors [at least obviously] and don't send messages to one another other then through these remote handle api - which is really just a form of proxy api:
@ray.remote
class Counter(object):
def __init__(self):
self.value = 0
def increment(self):
self.value += 1
return self.value
def get_counter(self):
return self.value
counter_actor = Counter.remote()
import pykka
class Calculator(pykka.ThreadingActor):
def __init__(self):
super().__init__()
self.last_result = None
def add(self, a, b=None):
if b is not None:
self.last_result = a + b
else:
self.last_result += a
return self.last_result
def sub(self, a, b=None):
if b is not None:
self.last_result = a - b
else:
self.last_result -= a
return self.last_result
actor_ref = Calculator.start()
We have wanted a proxy style wrapping for a few things in piker which is shown in small degrees in #190.
I would be interested to hear more opinions and complaints in this arena.
Though I'm pretty much entirely against apis of this sort:
triotask functions in separate thread sessions, communicating over our channels,trioexplicitly avoids and thus most of why you would want a method-as-callback api is moot,but, it seems users coming from the actor systems space are confused when they don't see apis of this sort.
Thus, I propose we at least have a (couple) recipe(s) to show how such things can be accomplished.
#190 is one effort on this front for @fjarri.
Some examples from the mentioned projects:
ray's actors are basically just classes instantiated and persisted in a thread - further I would argue these aren't real actors as in the actor model (they can't spawn other actors [at least obviously] and don't send messages to one another other then through theseremotehandle api - which is really just a form of proxy api:pykkahas a similar api but they actually have explicit message passing and call a remote handle api for what is is, a proxyWe have wanted a proxy style wrapping for a few things in
pikerwhich is shown in small degrees in #190.I would be interested to hear more opinions and complaints in this arena.