Related link: http://pyro.sourceforge.net/
I ran into a situation recently where I needed to pass “None” as a value to some code which runs under the SimpleXMLRPCServer in the Python standard library. I immediately got a Fault something like this:
<Fault 1: ‘exceptions.TypeError:cannot marshal None unless allow_none is enabled’>
I tried turning on allow_none by putting something like this in my XMLRPC client:
xmlrpclib.ServerProxy(”http://localhost:8000″, allow_none=1)
I never got this quite working, but by googling around, it seems that the XMLRPC spec doesn’t have support for a None datatype. I anticipate that I won’t need “None” much, but when you need it, you need it. I figured I could kludge something, but why?
I had heard people speak highly about Pyro for a while on comp.lang.python, but I had been hesitant to try it. My hesitation came from satisfaction with XMLRPC and not wanting to have to include an additional package in my code when I went to deploy it. One point of hesitation had just been removed. XMLRPC just wasn’t working for me. And having an extra package turned out to not be as big of a problem for me as I initially thought it would be.
I decided to give it a spin. It was really easy to just drop in a Pyro server where my SimpleXMLRPCServer had been. And it was another easy matter to replace the XMLRPC client code with Pyro client code. And “None” worked without a problem. I’ve been running it for a few months now and have had no problems with it.
I can enthusiastically recommend Pyro to anyone needing Python->Python interprocess communication.
Pyro does the job
Yes, I can only agree to what have been said. I never tried xmlprc though, but xml in the whole seems to be very un-pythonic.
I've been using Pyro massively in the last years, mainly to set-up a computational grid for financial calculation. It is very simple to use and fun to work with.
Not being born as an evangelist I really feel the need to act as one in favor of this nice little Pyro package.
Tim
XML-RPC is for cross toolkit stuff
Doing RPC between programs which use the same language/toolkit is almost always easier than using some form of standard for rather obvious reasons.
The same is true for eg ObjC DO (distributed objects) or RMI.
XML-RPC (and SOAP ...) is for tools which are loosly coupled (aka "web services"). Its harder to use (well, in Python is still very easy to use) but gives you interoperability in return.
To give an example it would be rather useless to write a Weblog API using Pyro ...
The 'None' issue. It isn't in the standard and you can't use it in "strict" XML-RPC. However there is the
http://ontosys.com/xml-rpc/extensions.php
As far as I can see from the libxmlrpc.py source code (2.4) your
xmlrpclib.ServerProxy("http://localhost:8000", allow_none=1)
should work just fine. If not, maybe filing a bug would help?
So if you already know that you will only do communications between tools in the same language, its pretty safe to assume that using XML-RPC or SOAP is likely to be harder than necessary.
But if you are fine with the data types provided by XML-RPC, its also very easy with Python and might be well worth the minor additional effort.
XML-RPC in Python standard library
Funny that. I ran into the None problem before - together with the problem that timezones aren't included in datetime marshalling but that's a different story.
After checking the source, I saw that xmlrpclib.ServerProxy has a parameter 'allow_none' (like you noted above) but the counterpart SimpleXMLRPCServer doesn't implement it. It seems that client and server were not written by the same people...
My workaround at the time was to create a PatchedSimpleXMLRPCServer module in which the SimpleXMLRPCServer class was overriding "SimpleXMLRPCDispatcher", "SimpleXMLRPCServer" and "CGIXMLRPCRequestHandler" and then change any "import SimpleXMLRPCServer" to "from PatchedSimpleXMLRPCServer import SimpleXMLRPCServer".
If you're interested in the code email me on danny(at)adair(dot)net
Pyro does the job
XML may not be "Pythonic" but do you really care about the internal representation? XML-RPC is a _simple_ way of wrapping a call between servers, light-weight and easy to debug. If you don't need more functionality, why introduce more complexity?
That said, when I ran into the "None" problem, I decided to patch.
Pyro does the job
Amusing... XML is un-Pythonic, so Pyro is better? But you have to use XML with Pyro, too! If you let it use Pickle, you are granting access to execute arbitrary code on your machine to anyone who can send you messages. I guess that's Pythonic, but XML isn't? :)
XML-RPC is for cross toolkit stuff
Great point about same vs. different language communication. I'm currently only doing Python->Python, so XMLRPC wouldn't really benefit me any more than Pyro does at the moment. I've been happy for quite a while with XMLRPC, but the None thing was a deal breaker. If I ever have the need to do SomeOtherLanguage->Python, I guess I'll either look into the patching solutions suggested or look into something like Corba.
Pyro does the job
Yes, point taken. My argumentation has been a bit naive ;-)
I agree: taking pickle for untrusted connections would be quite dangerous.
So please let me rephrase my comment: IMHO Pyro does a quite good job for interprocess communication or RPC over a trusted network.
But doing RPC with unknown counterparts or writing a web-API a XML based protocol (or JSON) would be the wiser choice.
benchmarks?
I found XMLRPC to be easy but fairlt slow. Is Pyro any better?
benchmarks?
Pyro is faster, by an order of magnitude. I just converted some code from xmlrpc to Pyro, and made a
contrived benchmark of some simplified versions of the methods as a test.. also the ease of flipping the code between xmlrpc and Pyro is shown, see:
the code here (
http://blog.zog.net.au/index.cgi/nerdy/Python_RPC_xmlrpc_and_Pyro.html)