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