E pur si muove

IPC in the stdlib(?)

Thursday, May 17, 2007

Many interesting comments on my last musings about IPC. Each and every one of them look very nice and have their application area, go and have a look! These found a weak spot in my heart though:

  • Candygram is Erlang style message passing. Very stunning, but to my liking a little bit too much Erlang-like. Nevertheless I was impressed.
  • The delegate module was probably the closest to what I was describing. And I'm surprised it's not better known.
  • Lastly I can't keep my mind off pylinda. From the moment I started to read about it I fell in love with it. It is Erlang-like enough to satisfy me and also has a huge potential even to talk to other languages. I'm not sure yet how it's API looks as I'd want to do things like running the server as part of the main process (and it being a private server as well then) etc. It got me excited allright.

All this is well though, but I'm not sure I made my main point very clear last time (and fear losing it here in the noise too, I must be a bad writer). Namely, non of this is in the stdlib (yes, xmlrpc is).

I do think there is a need for a good and yet simple pythonesque IPC module in the stdlib. When building cluster or grid systems it seems reasonable to me to stray outside of the stdlib (for now at least). But for simple SMP a module should be making it's way into the stdlib by now IMHO.

Given by what I've seen so far -but beware, I haven't used any of these yet- delegate seems like the best suited candidate. It may need some updating, I can imagine it benefitting from the subprocess module for example, but I certainly think something like it should live in the stdlib.

I wonder what the chances of that happening are.


Pete said...

I'm working on something kinda like this as part of a larger project.

Huh, I hadn't seen delegate before.

A.M. Kuchling said...

The best thing for stdlib acceptance would be to be able to point at a community of users of the package. If you propose adding a little-known package, or writing a new module, there's always concern over how you can know if the API is correct; does it actually meet user needs?

Second-best would be to write a detailed PEP, but I think the possible IPC approaches are so diverse that the PEP process wouldn't really work. A PEP might specify a tuplespace approach very well, for example, but people would then wonder "are tuplespaces really what users want?" and there's still no progress toward selecting a package.

I do think a good IPC mechanism would be an excellent addition to the stdlib, but there doesn't seem to be a most widely-used package.

Justin A said...

A class I wrote a while back is sort of like delegate, mine uses threads though:

I wrote it before I ever saw any Erlang code, but it is written in the same style of message passing. Re-writing it to use Candygram would be pretty easy. I wouldn't mind something as flexible as the message passing in Erlang to be available in python :)

New comments are not allowed.

Subscribe to: Post Comments (Atom)