Remove Copy and Clone derives from PyObject

[ngoldbaum]

Refs #4265 #4421 (comment).

It's almost certainly not correct for someone to allocate a PyObject struct outside of the Python runtime, so we shouldn't make it easy to do so. This is also needed for the free-threading work, where PyMutex is a field in PyObject.

The changes in the datetime FFI fix "cannot move out of a raw pointer" compiler errors. It was probably a bug that these datetime interfaces were copying a PyObject struct.

This is a breaking change and I need to add a changelog entry. Do FFI breaking changes show up in the migration guide? If so, do I need to suggest anything besides removing Copy and Clone from derived types?

[davidhewitt]

I think this is great as-is; I might write a more complete migration note for "FFI changes" as part of #4379. Thanks very much!

Hilarious to find that our datetime bindings were misusing the Copy nature of the struct. I think in practice the compiler would optimize away the full "move" here to just read the target field, but still... 🤦

[nichmor]

I would like to ask a follow up question - how one could implement Clone trait for PyObject?

I'm following the guide for exposing traits to python (https://pyo3.rs/main/trait-bounds.html)

so I end up with this small implementation:

#[pyclass]
pub struct PyGenerateRecipe {
    model: PyObject,
}

later I would like to accept it as an argument for a function, like this:

#[pyfunction]
fn py_main(
    instantiator: PyGenerateRecipe
) -> PyResult<()> {

    Ok(())
}

but it complains that for PyFunctionArgument it is required to have Clone implemented. ( which I can't derive for PyGenerateRecipe because of PyObject)

What is the right way to express this concept in pyo3?
Thanks!

[Icxolu]

I think there is a mixup here. This PR is about pyo3_ffi::PyObject the C structure from CPython. Your code is about pyo3::PyObject the type alias for Py<PyAny> (which we should arguable remove). Both do not implement Clone, for different reasons. The right way for your example is to accept instantiator by reference and not by value,
i.e. instantiator: &PyGenerateRecipe.

[nichmor]

I think there is a mixup here. This PR is about pyo3_ffi::PyObject the C structure from CPython. Your code is about pyo3::PyObject the type alias for Py<PyAny> (which we should arguable remove). Both do not implement Clone, for different reasons. The right way for your example is to accept instantiator by reference and not by value, i.e. instantiator: &PyGenerateRecipe.

oh thanks! Sorry for mixing the things

[ngoldbaum]

Sorry for mixing the things

It's an easy mistake to make. I agree that we should deprecate the alias because it's confusing.