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.