-
Notifications
You must be signed in to change notification settings - Fork 728
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fallible alternative to IntoPy? #1813
Comments
Yes, I absolutely agree that something should be done here. I think the overall question is just about defining a better iteration of PyO3's conversion traits. We already have |
Hey @davidhewitt is there any update on this? It feels like a pretty large chink in the armour. Because if IntoPy panics python ends up with a PanicException which is more than likely going to bubble up uncaught and crash the python process as it is based off BaseException. I could potentially help but curious if there is a fundamental reason this isn't fallible or hasn't been prioritised? |
No update, simple answer is that I haven't had time to invest into this particular issue. The challenges I see:
I'm hoping the best way forward it to start an initiative to discuss pyo3's conversion traits in general and how to simplify them, either iteratively or in a big bang. Proposals are welcome, although I think to be worth the adoption pain for our users we need to be reasonably sure that a new trait system would be be robust enough to be stable for a long time and have an update pathway which is easy to document. |
My project could use this feature ( I have a suggestion on how to implement this:
impl<Target, Value> TryIntoPy<Target> for Value where Value: IntoPy<Target> {
fn try_into_py(self, py: Python<'_>) -> PyResult<Target> {
Ok(self.into_py(py))
}
#[cfg(feature = "experimental-inspect")]
fn type_output() -> TypeInfo {
IntoPy<Target>::<Value>::type_output()
}
} I think this could work for pyo3/src/conversions/std/set.rs Lines 10 to 20 in cd4b27f
Those might need to be moved to the |
I have tried this, but the blanket implementation does not work, since it will not allow for infallible versions of things with fields like, |
Removed several unwraps and replaced them with `PyResult` returns. Some could not be removed due to PyO3's limitation to non-failable type conversions PyO3/pyo3#1813.
While
FromPyObject::extract()
returns with aPyResult
theIntoPy
conversion trait returns with aPyObject
making it hard to implement conversions which may return with an error.Tried to manually raise an exception, but unable to propagate the correct error:
Is there a workaround or plans to add support for a fallible IntoPy alternative?
A bit unrelated, but I'd like to mention that the current naming is a bit confusing, something like the following would better align with the rust conversion traits.
The text was updated successfully, but these errors were encountered: