how to use pyo3 correctly after v0.23?

[WeepingClown13]

So, pyo3 deprecated the usage of ToPy and ToPyObject in favor of IntoPyObject in v0.23 and removed the deprecated api in v0.25. I have managed to migrated something that was using pyo3 0.22 to 0.25 (context: it's the debian package for pendulum, and in debian we had pyo3 v0.22 and now are migrating to 0.25), but it's not really pretty. The patch that does the work can be seen here. This specific patch also drops the generate-import-lib feature usage, but that's a seperate debian related thing.

As you can see in the patch, it is riddled with method chainings and unwraps. I read the migrated guide and related discussions, but really couldn't find better methods. Also full disclosure that I am not primarily a rust guy, so several things you all find obvious might not be so for me. If you take the examples like foo.into_pyobject(py).unwrap().downcast().unwrap() that I am doing, that feels quite wacky, and I'd expect there to be some better way to do this (that code works, it's 50% understanding and 50% trial and error until something worked). Another thing is that, reading up quite bit I initially thought the results with Infallible could be safely unwrapped, but now I am confused it might actually be the other way around.

So, what are the correct ways to use these now? I'd appreciate it if the explanations come in the context of my patch for pendulum, which can help me understand it better as well as upstream the patch.

PS: I know #4857 is there, but I am starting this seperate discussion hoping for a more beginner friendly discussion. Sorry if that is too much, but fwiw that one doesn't help me beyond a certain extend, and is already marked as answered.

[LilyAcorn]

You might be able to avoid the unwrap calls by allowing the errors to bubble up with ?.

Do you have a link to the full code that's being modified? I don't think there's enough context in the patch to give better advice and I don't know how to navigate that site.

[Icxolu]

From a quick look at that file it looks like these are all Python objects already. So there is not really a need for IntoPyObject here, the to_object is a bit misused to upcast a Py<T> into a Py<PyAny>. This can be easier done by using Py::into_any (and after that downcasting is possible; with 0.26 it will be possible to skip this and just use cast directly, not upcast necessary anymore).

Regarding Infallible, it's an uninhabited type which means there are no values of that type, so it is save to unwrap. With a sufficiently new Rust compiler it is also possible to unwrap it "safely" at compile time like so:

let x: Result<usize, std::convert::Infallible> = Ok(42);
let Ok(y) = x; // no compile error here

In the far future this will probably turn into the never type !, at which point there might be something like a into_inner on Result<T, !>. But this is something will need additional support from the language and compiler.

[WeepingClown13]

@Icxolu thanks for that! I still don't know if this is correct, but I have nonetheless managed to turn it into a somewhat cleaner version. And the changes now look more minimal than before. For one, I am not sure if this is the correct way of using into_py_any() (by with a simple use pyo3::IntoPyObjectExt, although I know it works). This might look like I am sneakily asking for a code review, but I hope you can understand that it is much easier for me to understand with a context I am at least somewhat familiar with.

diff --git a/rust/src/python/parsing.rs b/rust/src/python/parsing.rs
index 4984c68..1b01ca0 100644
--- a/rust/src/python/parsing.rs
+++ b/rust/src/python/parsing.rs
@@ -6,2 +6,3 @@ use pyo3::types::PyDateTime;
 use pyo3::types::PyTime;
+use pyo3::IntoPyObjectExt;
 
@@ -33,3 +34,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
                                 Py::new(py, FixedTimezone::new(offset, datetime.tzname))?
-                                    .to_object(py)
+                                    .into_any()
                                     .downcast_bound(py)?,
@@ -38,3 +39,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
 
-                        Ok(dt.to_object(py))
+                        Ok(dt.into_py_any(py)?)
                     }
@@ -53,3 +54,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
 
-                        Ok(dt.to_object(py))
+                        Ok(dt.into_py_any(py)?)
                     }
@@ -64,3 +65,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
 
-                    Ok(dt.to_object(py))
+                    Ok(dt.into_py_any(py)?)
                 }
@@ -76,3 +77,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
                                 Py::new(py, FixedTimezone::new(offset, datetime.tzname))?
-                                    .to_object(py)
+                                    .into_any()
                                     .downcast_bound(py)?,
@@ -81,3 +82,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
 
-                        Ok(dt.to_object(py))
+                        Ok(dt.into_py_any(py)?)
                     }
@@ -93,3 +94,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
 
-                        Ok(dt.to_object(py))
+                        Ok(dt.into_py_any(py)?)
                     }
@@ -113,3 +114,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
             )?
-            .to_object(py)),
+            .into_py_any(py)?),
             (_, _, _) => Err(exceptions::PyValueError::new_err(

[Icxolu]

For one, I am not sure if this is the correct way of using into_py_any() (by with a simple use pyo3::IntoPyObjectExt, although I know it works).

I'd say it's a valid way to do it. In this specific case (dt already is a Bound) there is also the alternative way of using dt.into_any().unbind() (which is what into_py_any does internally after performing the conversion using into_pyobject)

[WeepingClown13]

@Icxolu Thank you! I think I have a much better understanding of it now. Since the answers are fragmented throughout, I'll just add the full patch that I have now ended up with for completions sake, and mark it as answer. I really appreciate the help!

diff --git a/rust/src/python/parsing.rs b/rust/src/python/parsing.rs
index 4984c68..cc4c250 100644
--- a/rust/src/python/parsing.rs
+++ b/rust/src/python/parsing.rs
@@ -6,2 +6,3 @@ use pyo3::types::PyDateTime;
 use pyo3::types::PyTime;
+use pyo3::IntoPyObjectExt;
 
@@ -33,3 +34,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
                                 Py::new(py, FixedTimezone::new(offset, datetime.tzname))?
-                                    .to_object(py)
+                                    .into_any()
                                     .downcast_bound(py)?,
@@ -38,3 +39,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
 
-                        Ok(dt.to_object(py))
+                        Ok(dt.into_any().unbind())
                     }
@@ -53,3 +54,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
 
-                        Ok(dt.to_object(py))
+                        Ok(dt.into_any().unbind())
                     }
@@ -64,3 +65,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
 
-                    Ok(dt.to_object(py))
+                    Ok(dt.into_any().unbind())
                 }
@@ -76,3 +77,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
                                 Py::new(py, FixedTimezone::new(offset, datetime.tzname))?
-                                    .to_object(py)
+                                    .into_any()
                                     .downcast_bound(py)?,
@@ -81,3 +82,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
 
-                        Ok(dt.to_object(py))
+                        Ok(dt.into_any().unbind())
                     }
@@ -93,3 +94,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
 
-                        Ok(dt.to_object(py))
+                        Ok(dt.into_any().unbind())
                     }
@@ -113,3 +114,3 @@ pub fn parse_iso8601(py: Python, input: &str) -> PyResult<PyObject> {
             )?
-            .to_object(py)),
+            .into_py_any(py)?),
             (_, _, _) => Err(exceptions::PyValueError::new_err(

[ravenexp]

This specific patch also drops the generate-import-lib feature usage, but that's a seperate debian related thing.

I'm curious why this is the case. This feature does nothing when targeting Linux-based platforms (supposedly).

[WeepingClown13]

Precisely, that means we have no reason to enable the feature, especially if it helps avoiding a dependency chain. And in this specific case, the dependencies that actually provide this feature does not enable it either, for the same reason, so there's not way to enable it here either (I'd disable it either way, nonetheless).

[WeepingClown13]

Another reason to disable unnecessary features is that, our tooling basically creates semver compatible virtual packages x4 (not actual packages, but these are provided by the actual package for download) for each enabled feature. And if we could avoid them without any drop in functionality, that's a sound reason to disable it.