PR #52 introduced a code path to ghostify that calls PyErr_Clear() with the intent to avoid propagating AttributeErrors for slots.
However, if there is an error (like a POSKeyError) raised by jar.setstate(), then unghostify will call ghostify with an error pending. If the object had slots that weren't set and the AttributeError was cleared, so was the pending error from setstate. So when ghostify returned NULL that got propagated up to the interpreter which finds no exception and so raises SystemError: error return without exception set.
This commit makes unghostify save and restore the exception state around the call to PyErr_Clear so the real exception is raised, rather than the baffling and unhelpful SystemError.
PR #52 introduced a code path to
ghostify
that calls PyErr_Clear() with the intent to avoid propagatingAttributeErrors
for slots.However, if there is an error (like a POSKeyError) raised by jar.setstate(), then
unghostify
will callghostify
with an error pending. If the object had slots that weren't set and theAttributeError
was cleared, so was the pending error from setstate. So whenghostify
returned NULL that got propagated up to the interpreter which finds no exception and so raisesSystemError: error return without exception set
.This commit makes
unghostify
save and restore the exception state around the call toPyErr_Clear
so the real exception is raised, rather than the baffling and unhelpful SystemError.