Zac Bentley <zbbent...@gmail.com> 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_Display, then PyErr_Restore") does not work well: if code runs in a boost-python destructor which runs during async return time, how would it tell the difference between a "real" exception raised from within whatever function is currently returning and the "fake" StopIteration exception that is in the error global while an async function returns? Aka, this code would not have any way to function properly: async def func(): thing = MyNativeCodeObject() raise ValueError() The destructor for MyNativeCodeObject would have to perform a complex check, and PyErr_Restore/do nothing IFF the following are all true: - Is there an exception currently being handled/in the global? - Is that exception a StopIteration? - Is the interpreter currently in the process of returning from an async function (I'm not sure how to check this)? The fact that non-StopIteration exceptions are handled correctly (e.g. the ValueError in the above example makes it out of the async call during "await func()") means, I think, that there's already some secondary exception storage mechanism that's used to stash and restore user exceptions while the async machinery raises StopIteration to return from an async function. Could that same mechanism be used to "hide" the StopIteration from user code that runs during async-return time? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45033> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
