In an attempt to record the xml exchange in an xmlrpclib.ServerProxy connection, I set its verbose flag to 1. This is the whole premise, and the rest of this message contains a bug report, and general complaints about the API.
ServerProxy, or to be a bit more specific, the Transport class (which does all the actual printing), provides very little control over where the output goes. By very little, I mean it only outputs to stdout, which is limiting in a server environment where many a prints occur.
That, however, turned out to be the least of my worries: xmlrpclib depends on httplib.HTTP to print the outgoing data, but prints its own incoming data, and they tend to collide, in what I permit myself to call a "race condition", though it's mostly just simple lack of management of a shared resource (stdout). The resulting output is mostly well-formed, with the occasional nonsense produced by an interjection of one string to the middle of the other.
Also, there's the nasty business of Transport.request accepting a 'verbose' param, and then setting it as an instance attribute and using *that*, for no apparent reason except to cause yet another potential race condition.
I suggest that httplib.HTTP's verbosity will be controlled by a separate flag, if controlled at all. The outgoing communication can easily be printed by transport, allowing for better control of synchrony. Also, ServerProxy should accept an optional output file (=a class with write,writelines methods), which will be the target of all prints.
Would Python be interested in such a patch?
Best Regards, Erez
On Wed, Feb 02, 2011 at 03:52:17PM +0200, Erez Sh wrote:
Also, ServerProxy should accept an optional output file (=a class with write,writelines methods), which will be the target of all prints.
Why not logging?