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
{{ message }}
Repository navigation
ENH: dtype API needs an API slot for a single-element copy #24859
Currently, users will see seg faults if a user-defined dtype is passed somewhere where copyswap is used internally to copy array elements.
If we require that user-defined dtypes implement a single-element copy operation we will be able to implement a default copyswap implementation for user-defined dtypes which can be used where copyswap is used internally in NumPy.
There are two slightly different use-cases here. In most cases, where we need a single element copy, we actually need to copy many, which means preparation is useful/necessary. But in some we may not need it.
The question is how we deal with allowing preparation (noting that for the majority of dtypes the preparation would be at best specializing for short copies or alignedness and it would be good if NumPy just provides that copy function for those without references at least.).
Activity
seberg commentedon Oct 9, 2023
There are two slightly different use-cases here. In most cases, where we need a single element copy, we actually need to copy many, which means preparation is useful/necessary. But in some we may not need it.
The question is how we deal with allowing preparation (noting that for the majority of dtypes the preparation would be at best specializing for short copies or alignedness and it would be good if NumPy just provides that copy function for those without references at least.).
seberg commentedon Jan 31, 2024
We should do this, but probably not a disaster if it's not in 2.0, I think.
copyswap/copyswapncalls segfault for new-style user DTypes #30795 as a duplicate of this issuengoldbaum commentedon Feb 6, 2026
#30795 has some more motivating examples for how this is still annoying