i don't feel i may join in this discussion as i'm certainly biased, but i don't want to just leave it on the wall. for those of you who haven't heard of rpyc, here's a link: http://rpyc.wikispaces.com/ and a short demo/tutorial at http://rpyc.wikispaces.com/tutorial
i can bring many use cases that demonstrate rpyc's superiority over other RPC mechanism, but then again, rpyc has its drawbacks too (mainly security and frequent IOs). i can make a list of both pros and cons, but i don't see how it could advance this discussion.
just some final words, as guilherme has said, i am now actively working on rpyc3.0. in fact the core (parallel to rpyc2.6) is already stable and quite tested (you can find it on the svn), but if any attempt is made to integrate rpyc into the stdlib, it should wait until the final 3.0 release.
On Mar 24, 12:31 pm, "Guilherme Polo" ggp...@gmail.com wrote:
2008/3/24, Tal Einat talei...@gmail.com:
On Mon, Mar 24, 2008 at 1:03 AM, Brett Cannon br...@python.org wrote:
On Thu, Mar 20, 2008 at 8:45 AM, Guilherme Polo ggp...@gmail.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.
I've talked with him before posting this here Tal. Also, the development of the new version is active.
-- -- Guilherme H. Polo Goncalves _______________________________________________ Python-ideas mailing list Python-id...@python.orghttp://mail.python.org/mailman/listinfo/python-ideas