On Mon, Mar 24, 2008 at 1:03 AM, Brett Cannon firstname.lastname@example.org wrote:
On Thu, Mar 20, 2008 at 8:45 AM, Guilherme Polo email@example.com wrote:
I've read this idea about "preparing an existing RPC mechanism for the standard library" at StandardLibrary ideas and I would be interested in doing it, but as you all know, including something into stdlib is not exactly easy and shouldn't be anyway. Also I'm not even sure if this idea is still desired.
I'm considering the inclusion of rpyc, with appropriate changes (possibly lots). And would like to know your opinions towards this.
I know from my end I am not even familiar with rpyc so I have no comment. And I suspect most other people have a similar reason for having not commented on this so far.
I believe the reason that the OP is considering RPyC is because it is the most Pythonic RPC mechanism of the lot. That, and its relative simplicity, are the reasons I recently chose RPyC for a project, and it worked out pretty well. If any RPC mechanism is added to the standard library, I hope it has an API as Pythonic as RPyC's!
I ran into two main problems while using RPyC (v2.60), neither of them show breakers for me. The first was that debugging it can be hard because its exception handling (propagation across the RPC link) isn't good enough (yet). The second is that the RPC is two-way and very transparent, so that once the application became complex I had to take special measures to avoid deadlocks. All things considered, RPyC got the job done.
I know RPyC's developer and maintainer, Tomer Filiba, and he's a great guy, though recently much busier than he used to be. He had plans to add distributed computing capabilities to RPyC in version 3.0, and probably quite a few other features, but AFAIK development is currently frozen. I'm CC-ing the RPyC newsgroup in hopes that he (and the users) will comment on this.