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
Due to issues making delay reference count increments sound, they were removed #4095 and replaced by an Clone implementation for Py which will panic without the GIL being held, gated by the py-clone feature.
This has several usability downsides, e.g. #[pyo3(get)] stops working with Py<T> fields which however is a very important use case when sharing data with Python code. Similarly, the PyBacked* types cannot be unconditionally Clone themselves.
Both problems (and likely others) should be resolvable if we add a trait, e.g. CloneRef or PyClone with signature
fnclone_ref(&self,py:Python<'_>) -> Self;
and implement it unconditionally for Py<T> and add a blanket impl based on Clone. The proc macro machinery behind #[pyo3(get)] could then go via this trait instead of the plain Clone.
The text was updated successfully, but these errors were encountered:
and this also does not really end because set for which we would want to provide PyClone is open-ended.
(It also conflicts with the PyClone impl for Py if the py-clone feature is enabled, but we could suppress that.)
So I don't think it is possible to make this as seamless as Clone especially considering types outside of our purview.
The only reasonable idea I currently have is to again make use of use being in macro context when we call clone in impl_py_getter_def, meaning we use autoref specialization to prefer calling clone_ref if it exists and fallback to clone otherwise. Meaning we also do not provide a blanket impl of PyClone at all and implement it for our types and some basic ones like Option and Vec.
What do people think? Hopefully anybody finds a better approach. I will really feel bad about adding yet another case of autoref specialization to our proc macros...
Due to issues making delay reference count increments sound, they were removed #4095 and replaced by an
Clone
implementation forPy
which will panic without the GIL being held, gated by thepy-clone
feature.This has several usability downsides, e.g.
#[pyo3(get)]
stops working withPy<T>
fields which however is a very important use case when sharing data with Python code. Similarly, thePyBacked*
types cannot be unconditionallyClone
themselves.Both problems (and likely others) should be resolvable if we add a trait, e.g.
CloneRef
orPyClone
with signatureand implement it unconditionally for
Py<T>
and add a blanket impl based onClone
. The proc macro machinery behind#[pyo3(get)]
could then go via this trait instead of the plainClone
.The text was updated successfully, but these errors were encountered: