[issue45033] Calls to PyErr_PrintEx in destructors cause calling async functions to incorrectly return None

Zac Bentley added the comment: For context (copied from the linked GitHub issue), this has affected at least two OSS projects: https://github.com/apache/pulsar/issues/11823 https://github.com/tbodt/v8py/issues/45 The proposed alternative ("PyErr_Fetch, then PyErr_Di

[issue45033] Calls to PyErr_PrintEx in destructors cause calling async functions to incorrectly return None

Zac Bentley added the comment: Irit, the documentation is clear. However, the problem is that the presence of StopIteration in the exception global during async return time causes very unexpected behavior. If, during async return time (in the linked issue, I do this in a boost-python

[issue45033] Calls to PyErr_PrintEx in destructors cause calling async functions to incorrectly return None

New submission from Zac Bentley : If an object's destructor contains native code which calls PyErr_PrintEx, and that object's refcount drops to zero as the result of an async function returning, the async function incorrectly returns None. I first identified this behavior while using Boost