04.03.2011 15:16, Tomer Filiba kirjoitti:
yes, well, i haven't heard of execnet either, but it looks more like a
competitor of the new multiprocessing module.
I see it as a direct competitor to RPyC's slave mode. I'd see myself
using execnet when I want to bridge different Python interpreters (e.g.
Python 3 + Python 2 or Python + Jython).
on the PR front, it's better to compare how simple rpyc is, versus the
alternatives:
* pyro - complicated setup (requires name servers, etc.)
* xmlrpc - very limited scope
* soap / wsdl - overly complicated, slow, bloated
* multiprocessing - limited scope (doesn't have proxies, etc.)
* execnet - from what i read, it seems to aim at remote code
execution. rpyc doesn't aim there.
if you want remote code execution with rpyc, just do
c = rpyc.classic.connect(...)
c.execute("code to run remotely")
anyway, it's not the speed that seems the edge here. rpyc is quite
efficient and uses a compact binary protocol -- but the main benefits are:
* ease of use
* minimal setup: import rpyc; c = rpyc.connect(...);
c.root.do_something(...)
* transparency - can work with existing code that expects "real" objects
* symmetry - both client and server can process requests, allows for
callbacks, async execution, etc.
-tomer
An NCO and a Gentleman
On Fri, Mar 4, 2011 at 14:59, Fruch <[email protected]
<mailto:[email protected]>> wrote:
First time I've heard about Execnet, and I think it's not match
to simplistic api of the classic SlaveService
the whole "Share-Nothing" and confusion channels send/receive, to
much for me to warp my head with.
I think we could beat them in PR.. :)
Now I need a way to compare between them (speed wise)
even the RPyC tutorial looks better then their documentation.
On Friday, March 4, 2011 1:39:01 PM UTC+2, Alex Grönholm wrote:
04.03.2011 08:02, Fruch kirjoitti:
Hi all,
I'm starting what I've committed to.
I have a way of first, keep bugs that already happened out of
the system, and then look for the new one.
1.
I have a small request from people who report issues, or
submit bug.
If you could write a test for a problem you see, so could add
it to our testing pool.
(and also use it when a fix is needed)
*Tomer*, can you add a tag in the github, for marking issues
that needed to have a test for ?
that way I could go over then and try to write a test for them.
2.
I want to measure the performance of rpyc,
(this is the first degree of PR, showing nice graph to prove
it's working faster then other solutions :) )
and I need some idea on how to measure, and what are the
"rivals" we want to compare with .
Execnet is probably the closest competitor. It has support for
Python 3.x, Jython and PyPy, which RPyC currently lacks (at
least for the first two). RPyC has the advantage of a more
liberal license (ExecNet is GPL), making it more viable for
use in commercial applications.
Fruch
