MAINT: Refactor PyArray_IntpFromIndexSequence into PyArray_IntpFromIndexArray #13407
Conversation
9bc9cd3 to
9612c18
Compare
| /* | ||
| * After the deprecation the PyNumber_Check could be replaced | ||
| * by PyIndex_Check. | ||
| * FIXME 1.9 ? |
There was a problem hiding this comment.
This is already handled within PyArray_IntpFromIndexSequence on line 131 - all this did was forbid objects that implement __index__ but neither __int__ nor __float__, and try to produce better error messages. The former was a waste of time, and the latter is now handled by catching TypeError and replacing the message on line 147
The deprecation this refers to was eliminated a long time ago.
9612c18 to
0b7b8d3
Compare
There was a problem hiding this comment.
Can't find anything to nitpick (should read the non-diff code once more at some point).
The only thing I find strange is that chunk of code in methods.c, but maybe I am missing things. Should we just deprecate that PyArray_MIN while we are at it (I do not care much either way)? The multiarray.c check would be unnecessary in the future then.
| @@ -974,7 +986,30 @@ PyArray_IntpFromIndexSequence(PyObject *seq, npy_intp *vals, npy_intp maxvals) | |||
| NPY_NO_EXPORT int | |||
| PyArray_IntpFromSequence(PyObject *seq, npy_intp *vals, int maxvals) | |||
There was a problem hiding this comment.
I wonder if we should deprecate that maxvals thing. Well, not providing it, but using the minimum. If maxvals is smaller, it should really be an error and not just ignore things.
There was a problem hiding this comment.
If we do that, we'd just deprecate this whole function in favor of the other one.
There are two things going on there:
We could simplify things a bunch if we allowed |
|
Yeah, the min length semantics are weird (though I think you can hack around them), but then this code path is somewhat more restrictive as well, which may be good, so I do not mind. Frankly, if we really wanted to micro-optimize, we should probably do an |
…dexArray There was some clumsy juggling of lengths in PyArray_IntpConverter where we ask for the length of the argument twice, and try to handle wrapping the object twice too. This fixes some bugs that probably no one ever will or did see: * A corrupt pickle file with an `shape` array that is too long would be silently truncated * An object that returns different `__len__`s each time it is asked will no longer fail * IntpFromSequence would overflow it's output buffer if nd == 0 This collapses `PyArray_IntpFromIndexSequence` back into `PyArray_IntpFromSequence`, since the former no longer has any callers (and is internal). Also update a test to fail with a more useful message.
Co-Authored-By: eric-wieser <[email protected]>
c76e027 to
a43c29f
Compare
|
@eric-wieser this still has the WIP label |
|
I think I had some more cleanup to these functions locally - I'll see if I can revive it. |
|
My guess is, that this one can be considered superseded by gh-20175 anyway. I did not remember this start. |
There was some clumsy juggling of lengths in PyArray_IntpConverter where we ask for the length of the argument twice, and try to handle wrapping the object twice too.
This fixes some bugs that probably no one ever will or did see:
shapearray that is too long would be silently truncated__len__s each time it is asked will no longer failThis collapses
PyArray_IntpFromIndexSequenceback intoPyArray_IntpFromSequence, since the former no longer has any callers (and is internal)