8 ms·

Pykka - Actors For Python

58 points by SkyMarshal 15y ago

halayli 15y ago
How is it different from xmlrpclib? http://docs.python.org/library/xmlrpclib.html#example-of-client-usage http://docs.python.org/library/xmlrpclib.html#example-of-cli...
- meeb 15y ago
  They're not even comparable. xmlrpclib is a library for remote procedure call. Pykka provides an implementation of the Actor model, which is a model of concurrent computation.
  - apgwoz 15y ago
    WikiPedia defines 3 basic things that make up actors: * send a finite number of messages to other actors; * create a finite number of new actors; * designate the behavior to be used for the next message receives. Now, I'm not saying that xmlrpclib and actors are the same, but one could implement a system that has these properties using xmlrpclib as the basis of transport, and to "designate the behavior to be used for the next message receieves." The way you'd designate is the message you sent, is the handler that gets run. And, if you want to get even more actor like, run xmlrpc servers in their own threads. But, yeah, a real actor system would probably never do this.
- jodal 15y ago
  I'm not that familiar with xmlrpclib, but as far as I know from a quick look xmlrpclib lets two programs, possibly running on different computers, communicate over HTTP. Pykka helps multiple threads (or eventlets if using pykka.gevent) in a single program to communicate in a safe and easy matter without requiring the developer to manage locks and whatnot that he would have if he used plain threads. Under the hood Pykka is just an abstraction on top of threads and queues. It's not uncommon for actor frameworks, like Akka, to support communication between actors on different computers, but there is currently no support for remote actors in Pykka.
srparish 15y ago
The name made me hope that it would let you communicate from python with akka actors. Apparently not.
magnusmorton 15y ago
Won't the GIL really limit the performance of this?
- tbatterii 15y ago
  sweet, I was wondering when someone was going to mention the GIL, now the fun can start. http://dabeaz.blogspot.com/2012/03/pycon-2012-followup.html http://dabeaz.blogspot.com/2012/03/pycon-2012-followup.html "In any case, the performance of threads is highly specific to the application at hand. You can't just take some benchmark from one of my GIL talks and extrapolate that out to a general statement about all Python thread programming. Personally, I find that Python threads have worked pretty well for most of the problems where I've used them. Of course your mileage might vary." So.... maybe, it depends on what you are doing. Personally I would have been happy to see ProcessingActor in pykka, maybe with 0mq for the ipc. That would be cool, but this looks useful nonetheless.
  - apgwoz 15y ago
    the multiprocessing module has "Managers" which can be used for IPC. I'm guessing that you could just communicate with those via Unix sockets, or TCP sockets on 127.0.0.1 and get pretty comparable results with 0mq, no? I've been using managers over TCP for use as an image cache (the program is essentially an image resizing proxy), and in my limited benchmarks, it's fast enough. Now, this isn't some real-time trading application, so maybe 0mq would squeeze something, but TCP/Unix sockets is probably fast enough for most purposes here.
    - tbatterii 15y ago
      well for me , 0mq makes ipc easy, I'm not too concerned about performance myself. though I do enjoy it. :)
- bascule 15y ago
  Not on Jython, which has no GIL by virtue of the JVM. Work on Jython has recently resumed and the new work is focusing on adding InvokeDynamic support, which I think is really exciting. (I say this all as a Rubyist who as seen these same problems on the Ruby side)
chaostheory 15y ago
Actor model concurrency is way more fun and easy to use than handling threads on your own. It's really nice to see this coming to Python. Let's just hope that this project doesn't get neglected like the one for Ruby.
- ruxkor 14y ago
  Apparently this was already done for python a few years ago: I just discovered a very similar, albeit older project that essentially does the same (i.e. implementing the actor model on top of threads, greenlets or stacklets) http://osl.cs.uiuc.edu/parley/ http://osl.cs.uiuc.edu/parley/ The most important part, i.e. the download section, seems to be down though.
inportb 15y ago
The fun thing is that Pykka works with Gevent. Now, if only it did networking too...
reinhardt 15y ago
Wondering how it compares with Pyro4 (at least if such comparison actually makes sense)
bascule 15y ago
Hi there, I'm working on a similar actor library in Ruby: http://celluloid.io/ http://celluloid.io/ The main thing I'd like to say is that there is a well-researched way to combine actors and object oriented programming. After stumbling upon this particular combination myself, I discovered it had been done a decade and a half earlier in Python: http://python.org/workshops/1997-10/proceedings/atom/ http://python.org/workshops/1997-10/proceedings/atom/ I believe the original source code has since been lost, but I would strongly encourage you to read their paper. Actor-based concurrent object oriented programming makes using actors as transparent as using objects.

58 points by SkyMarshal 15y ago

How is it different from xmlrpclib? http://docs.python.org/library/xmlrpclib.html#example-of-client-usage http://docs.python.org/library/xmlrpclib.html#example-of-cli...

meeb 15y ago
They're not even comparable. xmlrpclib is a library for remote procedure call. Pykka provides an implementation of the Actor model, which is a model of concurrent computation.
- apgwoz 15y ago
  WikiPedia defines 3 basic things that make up actors: * send a finite number of messages to other actors; * create a finite number of new actors; * designate the behavior to be used for the next message receives. Now, I'm not saying that xmlrpclib and actors are the same, but one could implement a system that has these properties using xmlrpclib as the basis of transport, and to "designate the behavior to be used for the next message receieves." The way you'd designate is the message you sent, is the handler that gets run. And, if you want to get even more actor like, run xmlrpc servers in their own threads. But, yeah, a real actor system would probably never do this.
jodal 15y ago
I'm not that familiar with xmlrpclib, but as far as I know from a quick look xmlrpclib lets two programs, possibly running on different computers, communicate over HTTP. Pykka helps multiple threads (or eventlets if using pykka.gevent) in a single program to communicate in a safe and easy matter without requiring the developer to manage locks and whatnot that he would have if he used plain threads. Under the hood Pykka is just an abstraction on top of threads and queues. It's not uncommon for actor frameworks, like Akka, to support communication between actors on different computers, but there is currently no support for remote actors in Pykka.

srparish 15y ago

The name made me hope that it would let you communicate from python with akka actors. Apparently not.

magnusmorton 15y ago

Won't the GIL really limit the performance of this?

tbatterii 15y ago
sweet, I was wondering when someone was going to mention the GIL, now the fun can start. http://dabeaz.blogspot.com/2012/03/pycon-2012-followup.html http://dabeaz.blogspot.com/2012/03/pycon-2012-followup.html "In any case, the performance of threads is highly specific to the application at hand. You can't just take some benchmark from one of my GIL talks and extrapolate that out to a general statement about all Python thread programming. Personally, I find that Python threads have worked pretty well for most of the problems where I've used them. Of course your mileage might vary." So.... maybe, it depends on what you are doing. Personally I would have been happy to see ProcessingActor in pykka, maybe with 0mq for the ipc. That would be cool, but this looks useful nonetheless.
- apgwoz 15y ago
  the multiprocessing module has "Managers" which can be used for IPC. I'm guessing that you could just communicate with those via Unix sockets, or TCP sockets on 127.0.0.1 and get pretty comparable results with 0mq, no? I've been using managers over TCP for use as an image cache (the program is essentially an image resizing proxy), and in my limited benchmarks, it's fast enough. Now, this isn't some real-time trading application, so maybe 0mq would squeeze something, but TCP/Unix sockets is probably fast enough for most purposes here.
  - tbatterii 15y ago
    well for me , 0mq makes ipc easy, I'm not too concerned about performance myself. though I do enjoy it. :)
bascule 15y ago
Not on Jython, which has no GIL by virtue of the JVM. Work on Jython has recently resumed and the new work is focusing on adding InvokeDynamic support, which I think is really exciting. (I say this all as a Rubyist who as seen these same problems on the Ruby side)

chaostheory 15y ago

Actor model concurrency is way more fun and easy to use than handling threads on your own. It's really nice to see this coming to Python. Let's just hope that this project doesn't get neglected like the one for Ruby.

ruxkor 14y ago
Apparently this was already done for python a few years ago: I just discovered a very similar, albeit older project that essentially does the same (i.e. implementing the actor model on top of threads, greenlets or stacklets) http://osl.cs.uiuc.edu/parley/ http://osl.cs.uiuc.edu/parley/ The most important part, i.e. the download section, seems to be down though.

inportb 15y ago

The fun thing is that Pykka works with Gevent. Now, if only it did networking too...

reinhardt 15y ago

Wondering how it compares with Pyro4 (at least if such comparison actually makes sense)

bascule 15y ago

Hi there, I'm working on a similar actor library in Ruby: http://celluloid.io/ http://celluloid.io/ The main thing I'd like to say is that there is a well-researched way to combine actors and object oriented programming. After stumbling upon this particular combination myself, I discovered it had been done a decade and a half earlier in Python: http://python.org/workshops/1997-10/proceedings/atom/ http://python.org/workshops/1997-10/proceedings/atom/ I believe the original source code has since been lost, but I would strongly encourage you to read their paper. Actor-based concurrent object oriented programming makes using actors as transparent as using objects.