DEP: Add back ndarray.__[sg]etslice__, but deprecate it
#8953
Conversation
|
Looks like indexing ends up calling {get,set}slice by default if they are there. I'd just remove the deprecation and wait until we drop 2.7. The main point here is to reuse the code for {get,set} item. After that, looks like one test failure will remain. |
|
@charris: Am I right in thinking that it makes sense to put this in |
3d72098 to
90204cd
Compare
|
I think you want this in I suspect you removed that yourself ;) |
I think that should work... |
|
Just needs the nosetester fix and I think it is ready to go. |
numpy/core/src/multiarray/methods.c
Outdated
| @@ -2417,6 +2417,44 @@ array_complex(PyArrayObject *self, PyObject *NPY_UNUSED(args)) | |||
| return c; | |||
| } | |||
|
|
|||
| static PyObject * | |||
There was a problem hiding this comment.
these need to be in an ifndef NPY_PY3K
These now delegate to __getitem__, so subclasses no longer need to define them
31960fd to
871bd93
Compare
|
@charris: Done, and with a more accurate commit message |
|
Merged. Thanks Eric. |
|
please rebase instead of merging master back in for these small branches. |
|
@juliantaylor: The merge here was deliberate - I wanted the parent of this commit to be the previous (merged) PR, so that it was easy to check what the sum total of changes was. |
|
Wouldn't a rebase have done as well? What am I missing? |
|
@charris: If I rebased, there would be no way to ask for a diff between this change and the one that it undoes, without getting everything in the middle (unless I rebased the already-merged PR, which would be weird, and create duplicate commits) |
|
Are you sure? What you would see would be the difference from current master head, which would look, IIANM, exactly like this does except with a cleaner history. |
|
Nothing. The difference would be what you see as a diff between f031cdf (the last non-merge commit in this PR) and 98b3127 (the commit before Github comparison link: 98b3127...f031cdf Had I rebased, that diff would include every intermediate commit on master. Of course, ideally I wouldn't have had to merge in the first place, and would have left it to github - but #8847 meant that a clean merge is not possible |
ndarray.__[sg]etslice__, but deprecate it
This is added in a way that means that CPython will not call these for
normal indexing.
This partially undoes #8592, and is a competing approach to #8943.
Other removals in #8592:
np.r_.__getslice__-np.r_is pretty broken anway (r_[array_of_objects,…] working when adding scalar but failing with object #4559 numpy.r_ seems to cache string beyond failing call #8815 BUG: numpy.r_ interprets first argument as array element when invoked with unicode #8818), and it seems really unlikely that anyone would actually call thisnp.ma.__getslice__- this falls through tondarray.__getslice__just fine nownp.nditer.__getslice__- seems incredibly unlikely someone would subclass thisBased on #8887, it's possible this causes a problem on pypy (in that
a[1:2]causes a deprecation warning) - can anyone test this?