BUG: Allow no-op clearing of void dtypes #23279
Conversation
Some void dtypes think they contain objects but don't. Instead of playing whack-a-mole to see if that can be fixed, simply make the clearing a no-op here for them. User dtypes are weirder, it should be OK to pass through. Fixes the error message and use write-unraisable. Closes numpygh-23277
| /* Free any internal references */ | ||
| if (PyDataType_REFCHK(fa->descr)) { | ||
| PyArray_ClearArray(self); | ||
| if (PyArray_ClearArray(self) < 0) { |
There was a problem hiding this comment.
Just to check I understand: to write a test for this, one would have to have a clearing function that actually misbehaves, correct? And the actual array object here is no longer accessible, hence NULL?
There was a problem hiding this comment.
Yes, it shouldn't be possible to reach this, but without the fix, you do.
| } | ||
| else if (dtype->type_num == NPY_VOID) { | ||
| /* | ||
| * Void dtypes can have "ghosts" of objects marking the dtype because |
There was a problem hiding this comment.
Should we have a separate issue to remind us to fix this?
There was a problem hiding this comment.
Maybe, we have been slowly chipping away at it. Some places still copy the whole data, until that is changed this is necessary.
There was a problem hiding this comment.
One point is, that so long we allow you to view a structured array as a bytes/unstructured void, this has to stay in place.
There was a problem hiding this comment.
Yes, I guess that makes sense - actually quite a mess if there is an object underneath. But, for another time!
|
Thanks Sebastian. |
3 participants
Some void dtypes think they contain objects but don't. Instead of playing whack-a-mole to see if that can be fixed, simply make the clearing a no-op here for them.
User dtypes are weirder, it should be OK to pass through.
Fixes the error message and use write-unraisable.
Closes gh-23277