You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the pyo3 Python<->Rust bindings, a Rust panic is propagated into its Python caller as a PanicException which derives directly from BaseException. This makes some sense from the point of view of Rust semantics (panics are supposed to be caught only in rare circumstances), but it causes problems when testing PyO3 code using Hypothesis.
I believe PanicExceptionshould derive from Exception, but other libraries may do things like this in the future. Currently, the only exception not considered a test failure if everyone follows the Python docs is KeyboardInterrupt, but the exceptions to actually be caught are whitelisted.
Perhaps we could implement a blacklist instead? Something like
My main concern is that this change would mean that errors people don't expect to catch would be caught, and then repeated in a loop - that can have various unfortunate side effects on the broader system. Given that you can also do:
Right, it does break behaviour. It's a little annoying to decorate all your tests with that, but I guess there's no helping it. In my case, I'll just add it to my hypothesis fork.
The sad thing about PanicException is that there's no way to get a handle on the object currently (see the missing TODO in the relevant issue ) so you can't quite do this. Instead one can do something like
exceptBaseExceptionase:
ifstr(type(e)) !="PanicException":
raisee# .... handle e as before
In the pyo3 Python<->Rust bindings, a Rust panic is propagated into its Python caller as a
PanicException
which derives directly fromBaseException
. This makes some sense from the point of view of Rust semantics (panics are supposed to be caught only in rare circumstances), but it causes problems when testing PyO3 code using Hypothesis.I believe
PanicException
should derive fromException
, but other libraries may do things like this in the future. Currently, the only exception not considered a test failure if everyone follows the Python docs isKeyboardInterrupt
, but the exceptions to actually be caught are whitelisted.Perhaps we could implement a blacklist instead? Something like
The text was updated successfully, but these errors were encountered: