-
Notifications
You must be signed in to change notification settings - Fork 725
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
Add trait for cloning while the GIL is held #4133
Comments
👍 I guess we probably want a derive macro for this trait too. |
I started to look into this and there are hurdles, for starters we really want the blanket impl impl<T> PyClone for T
where
T: Clone,
{
fn clone_ref(&self, _py: Python<'_>) -> Self {
self.clone()
}
} so that we can fall back to normal But this conflicts with necessary impls like impl<T> PyClone for Option<T> where T: PyClone;
impl<T> PyClone for Vec<T> where T: PyClone; and this also does not really end because set for which we would want to provide (It also conflicts with the So I don't think it is possible to make this as seamless as The only reasonable idea I currently have is to again make use of use being in macro context when we call 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... |
Uff, this kind of complexity sounds all too familiar to me.
I did indeed look into the specialization approach in #4254, and I used I at least didn't use autoref specialization and instead used type-level const logic to specialize, which might be an easier pill to swallow? 😂 |
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: