Zac Bentley <zbbent...@gmail.com> 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
object destructor), I write code like this:
try {
boost::python::call(somefunction);
} catch (boost::python::error_already_set e) {
PyErr_Print();
}
then two things go wrong:
1. The "catch" block runs even if "somefunction" did not raise, because
StopIteration is already in the exception handler.
2. When PyErr_Print clears StopIteration, the currently-returning async
function returns None, regardless of what it was supposed to return. I consider
this to be interpreter-induced data corruption.
I'm not sure what happens if user code raises an additional exception.
Do you think this is a Python bug, or a Boost bug? I'm not familiar enough with
interpreter internals to know whether or not there are other ways besides
boost-python destructors to get code to run "during async return". If there
are, I would definitely consider this a Python bug: PyErr_Print should not be
able to corrupt interpreter/return state.
----------
_______________________________________
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
