Summary
Pyro provides distributed objects over a network. You expose an object from one python process, and then access it from another python process just as if it was a local object (almost).
Pyro homepage has a good overview.
Pyro provides an optional Name Server, so that you can register (and look up) your remote objects in a hierarchial namespace.
Pyro provides an optional Event Server, so you can publish any pickleable Python objects as messages, labeled with arbitrary 'topic' strings. You can subscribe to topics, providing strings or regular expressions to filter which topics you're interested in.
Commentary
A few things I particularly like about Pyro 3.3 so far:
Better caliber documenation than most (all?) other Python packages I have worked with.
- Native to Python, and seems pretty natural and transparent to use from Python, compared with bridging to a different technology, e.g. CORBA or DCOM or RMI or RPC.
- Extensive and flexible configurability (config file, environment vars, runtime), but sensible defaults.
- Worked out-of-the-box for me, with a trivial amount of setup.
What I dislike about Pyro 3.3:
One gotcha is that following attributes more than one level deep (e.g. foo.somelist.sort()) gives you access to a local copy of the sub-object (namelist) rather than accessing the sub-object of the remote object on the server. The good news is that fixing this is on the list of improvements for an upcoming release.
I am planning to use Pyro for my current project. If you have experience with Pyro, drop me a line or post here. If you are curious about my experience with Pyro, stay tuned; I'll try to post some information here as I go. -- DanEverhart 2004/5/14
Pyro 3.4 has been released. With a brief scan of the changes, I didn't see anything compelling to me, so I haven't tried it yet. -- DanEverhart 2004/6/5
(more comments)