Why make into_py/to_object so complicated with into_pyobject?

[best2come]

Before 0.23 I could write:
x.into_py(py) or x.to_object(py) to convert x into a PyObject.
Now with 0.23 I have to write: xinto_pyobject(py).unwrap().unbind().into_any()

Why so complicated now? This is not an improvement for Rust developers to write much more code.

In addition into_pyobject comes with new problems. Like:

true.into_pyobject(py).as_deref().unwrap().unbind().into_any()

Produces an error that PyBool cannot be moved. So I don't know how to solve this. But the old implementation

true.into_py(py)

works like a charm.

Maybe some can help me with this issue?

Best regards,

Martin

[best2come]

Found a (better) solution:

Using into_py_any(py).unwrap() solves the issue and makes it nearly as easy as before.

[davidhewitt]

This is a very reasonable question. We had a number of pain points with .to_object() and .into_py() which we wanted to address when we replaced them with .into_pyobject(). The migration guide lists the advantages of the new single trait in https://pyo3.rs/v0.23.4/migration.html#new-intopyobject-trait-unifies-to-python-conversions

Rather than .unwrap() you should consider using ? and having your function allow for the possibility of failure. There are many to-Python conversions which might fail, such as set / dict creation (failure to hash elements), dates (out of range dates). Previously the .to_object() and .into_py() traits did not account for this and would lead users to have unexpected panics in their libraries.

As with the .into_py_any() function you found, that and the other methods on IntoPyObjectExt deal with common cases for various Rust containers you might want to end up with after a to-Python conversion.

Yes, the fact that all to-Python conversions now return results adds complexity which we haven't yet got a perfect answer for. Rust edition 2024 is expected to stabilise the ! type (the never type) which will hopefully lead to improvements in how cases like Result<Bound<'py, PyBool>, Infallible> can be "unwrapped". For this reason we haven't rushed to invent convenient helpers for the Infallible cases; this will probably be improved by the end of the year.

[mejrs]

which will hopefully lead to improvements in how cases like Result<Bound<'py, PyBool>, Infallible> can be "unwrapped".

This has been stabilized already 🎉