When working on the sets module, a bug was found where trapping an exception (a TypeError for a mutable argument passed to a dictionary) resulted in masking other errors that should have been passed through (potential TypeErrors in the called iterator for example).
Now, Walter is working on a bug for map(), zip(), and reduce() where errors in the getiter() call are being trapped, reported as TypeError (for non-iterability), but potentially masking other real errors in a __iter__ routine. The current proposed solution is to remove the PyErr_Format call so that the underlying error message gets propagated up its original form. The downside of that approach is that it loses information about which argument caused the error.
So, here's the bright idea. Add a function, PyErr_FormatAppend, that leaves the original message intact but allows additional information to be added (like the name of the called function, identification of which argument triggered the error, a clue as to how many iterations had passed, or anything else that makes the traceback more informative).
Python code has a number of cases where a higher level routine traps an exception and reraises it with new information and losing the lower level error detail in the process.