I just had a grueling experience debugging some unjellying problem. I wonder, why not make jelly tracebacks more useful by adding the details of the PB message that gave rise to them (i.e. which method of which object was called with which arguments). Any thoughts?

Good idea. I've incorporated this into newpb, where any problem during serialization or unserialization is reported via an exception that has a .where attribute. This .where string reports the location in the object graph that had the problem. In the case of serialization errors during an argument of a method call, you'd get a string with something like: <call-(reqID)-(objID)-(methodname)>.foo If you were to have something unserializable inside a container, the .where string would include the relevant index values: d = {'foo': 12, 'bar': Ephemeral()} l = [1, 2, d] rr.callRemote("doStuff", arg1=5, arg2=l) -> BananaError(where=<call-0-4-doStuff>.arg2[2]['bar']) Likewise, if one of the arguments violates a Schema constraint, the exception should give you enough information to figure out what exactly caused the problem. This occurs on both ends of the wire, so exceptions that occur when serializing the return value can be located too. The same .where technique is used during unserialization, so if someone sends you a serialized instance of a class that you are unaware of (or unwilling to deserialize), or if their value violates your inbound schema, you'll get an exception that has enough detail to help you figure out where exactly the problem was. cheers, -Brian