New submission from Zac Bentley <zbbent...@gmail.com>:
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-python. A more detailed description, and steps to reproduce, are in the issue report I filed on that library: https://github.com/boostorg/python/issues/374 I'm not very familiar with interpreter internals, so it is possible that this is expected behavior. However, it does seem like at least a leaky abstraction between the mechanics of async calls (which use exception based control flow internally) and the PyErr_PrintEx function, which is typically invoked by callers interested in finding out about errors that they caused, not errors that are both caused elsewhere and whose propagation is important to preserving call stack state. ---------- components: C API, Interpreter Core, asyncio messages: 400448 nosy: asvetlov, yselivanov, zbentley priority: normal severity: normal status: open title: Calls to PyErr_PrintEx in destructors cause calling async functions to incorrectly return None type: behavior versions: Python 3.9 _______________________________________ 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
