It does.PySys_Audit orw_init_refs may set an error on failure. The docs say that exceptions are due to marshalling itself.

True, those functions set errors as appropriate, apologies for being unclear. Various other error conditions are correctly reported, too. However unmarshallable objects like in this issue are not. AIUI they should raise aValueError: unmarshallable object (asPyMarshal_WriteObjectToString does), but the error is silently ignored byPyMarshal_WriteObjectToFile.

The problem is the errors are recorded inWFILE::error (e.g. see the end ofw_complex_object) and it is only in_PyMarshal_WriteObjectToString that is converted into an exception. This doesn't happen inPyMarshal_WriteObjectToFile.

This can be reproduced withpython -c "import _testcapi; _testcapi.pymarshal_write_object_to_file(int, 'test.data', 5)" (with assertions enabled). It asserts there are no exceptions raised after calling the function, but completes successfully. If you replaceint with{int} it will abort as expected.

I can reword or just drop the comment, whatever you prefer. Maybe something like, "TODO: this function silently ignores some failures due to unmarshallable objects"? I'd be happy to just fix it, for that matter, but I wasn't sure whether it would be considered worth the churn.

Now I look at that code again, I note the paths that currentlydo raise exceptions while writing objects are going to have them overwritten by that error handling code anyway. That's a shame, since they give specifics like "bad marshal data (unnormalized long data)" instead of a generic "unmarshallable object" message. Perhaps we shouldn't raise an exception if there's already one raised?