Spyne already had a complex_as setting for the representation of a complex value. I wanted to use a dictionary subclass that also exposed its keys as attributes, as in Threesixty and settingsd. The traversal could produce all the right member pairs, but its final constructor was hardcoded:
-d = dict(self._get_member_pairs(class_, inst))
+d = self.complex_as(self._get_member_pairs(class_, inst))That was the entire merged patch. The existing setting was consulted elsewhere for the list case, but the mapping path never called it. Substituting the configured constructor made the setting reach the operation it was supposed to control.
The change left traversal, member selection, and wrapper handling in place. A caller supplied a compatible constructor accepting the generated pairs; it did not need to copy the serializer just to select the resulting mapping.
This also makes the boundary of the feature clear. A custom mapping could change how the materialized object was used. It did not change which members the protocol generated, nor did it turn arbitrary constructors into valid serialization policies.