I proposed making Suds return a WebFault as the fault value in its (status, fault) tuple when faults=False. Callers could choose between an exception and a return value while keeping the same representation of the failure.
The practical problem was type checking: the raw Fault was a dynamically constructed Suds object, while a WebFault could be recognized with isinstance. I opened an issue and patch to make the return path consistent.
There was already code supporting that expectation. client.Method caught a WebFault and, when faults were disabled, returned (500, e). But the lower SOAP reply handler could return (500, fault) directly, bypassing that wrapper and leaving the caller with the raw object. I pointed out both paths in the discussion.
Tests against different services returned different raw fault types. Jurko Gospodnetić and I discussed making the option consistent across those paths.
The option also needed to distinguish failure modes. A service-supplied SOAP fault, malformed response XML, and a transport error are different failures. Jurko agreed that the implementation needed attention and that returning the exception seemed reasonable, but wanted those cases pinned down before changing the contract.
The patch never landed. The proposal was about making that choice predictable: change how the caller receives the failure without also changing which kind of object describes it.