[Python-ideas] Preparing an existing RPC mechanism for the standard library

Guilherme Polo ggpolo at gmail.com
Mon Mar 24 11:31:38 CET 2008


2008/3/24, Tal Einat <taleinat at gmail.com>:
> On Mon, Mar 24, 2008 at 1:03 AM, Brett Cannon <brett at python.org> wrote:
>  > On Thu, Mar 20, 2008 at 8:45 AM, Guilherme Polo <ggpolo 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



More information about the Python-ideas mailing list