[Python-ideas] Preparing an existing RPC mechanism for the standard library
tomerfiliba at gmail.com
Tue Mar 25 12:18:52 CET 2008
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... at gmail.com> wrote:
> 2008/3/24, Tal Einat <talei... at gmail.com>:
> > On Mon, Mar 24, 2008 at 1:03 AM, Brett Cannon <br... at python.org> wrote:
> > > On Thu, Mar 20, 2008 at 8:45 AM, Guilherme Polo <ggp... at gmail.com> wrote:
> > > > Hello,
> > > > 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.
> > - Tal
> -- Guilherme H. Polo Goncalves
> Python-ideas mailing list
> Python-id... at python.orghttp://mail.python.org/mailman/listinfo/python-ideas
More information about the Python-ideas