Just wondering, why is it possible to turn on unsafe tracebacks only at the server and not at the client? PB being symmetrical, this discrimination makes it arbitrarily difficuly to debug PB applications sometimes.

Hey, sorry for the slow response. It *is* possible to set the 'unsafeTracebacks' flag on both ends of the wire. PBServerFactory() takes a constructor argument to set this flag, while PBClientFactory() does not, but you can always set it after the fact: f = PBClientFactory() f.unsafeTracebacks = True I'm more inclined to resolve the asymmetry by removing the argument from PBServerFactory rather than adding it to PBClientFactory. As a debugging thing, I feel it isn't entirely appropriate to have as a constructor argument. However, I don't really feel that strongly about it either way. For the record, I'll describe a little bit more about what exactly this flag does, because there *is* a sense in which unsafe tracebacks can only be enabled on the "server" side of a given method call. The important thing to remember is that there are two different ways to divide the connection into "client" and "server" ends. Suppose you have program A, which has a pb.Referenceable named Alice that implements remote_foo. Likewise, you have program B, which contains a pb.Referenceable named Bob that implements remote_bar. Let us further suppose that program B used PBServerFactory and reactor.listenTCP to make the object Bob available to the world. Program A then used PBClientFactory and reactor.connectTCP to obtain a RemoteReference to Bob (and somehow passed a reference to Alice over to program B at the same time, so that both programs have a RemoteReference to the other's Referenceable). Now, the setting of this "unsafe tracebacks" flag on side A only affects tracebacks being sent *from* side A: that is, for exceptions that occur on side A, during a remote method invocation that was requested by side B. If you consider any given method call to have a "client side" (which requests the call by doing rref.callRemote("foo", args)), and a "server side" (which implements the method remote_foo(self, args)), then the unsafe-tracebacks flag is only relevant for the "server side". In our example, when B does alice.callRemote("foo"), B is the "client" side and A is the "server" side. If an exception occurs inside Alice's remote_foo method, it is the setting of A's clientfactory.unsafeTracebacks flag that determines whether's A's internal state will be exposed to B. On the other hand, when A does bob.callRemote("bar"), B is the "server" side, so it is B's serverfactory.unsafeTracebacks flag that matters. The important point is that the requesting side for any particular method call does not get to ask for an "unsafe traceback": only the owner of the sensitive information (in this case, the stack frames leading up to the exception, and the globals/locals that are in those stack frames) gets to decide whether or not to share it with the outside world. The second usage of the terms "client" and "server" here has to do with which side initiated the TCP connection and which side accepted it. This is how the PBClientFactory and PBServerFactory classes use these terms. Both of these classes have an 'unsafeTracebacks' flag, and if you set it to something non-zero, then any exception-raising methods invoked on that side will send back a full traceback to the other side. The minor asymmetry here (constructor argument versus set-the-flag-later) is just an oversight in the API. hope that's useful, -Brian