Avoid Index DeprecationWarning in Series getitem
State: closed

xref https://github.com/pandas-dev/pandas/issues/30867

cc @jorisvandenbossche. The alternative is to use a warnings filter inside SingleBlockManger.get_slice to filter the warning, but I think avoiding the warning in the first place is a bit nicer.

Labels:
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves
name: Warnings
description: Warnings that appear or should be added to pandas

Comments:
Oh, I got who calls what backwards here... Will need to re-think things...

We don't want to change all the index subclasses `__getitem__`s to do the `_getitem_deprecate_nd` version that maybe silences warnings.
Changed to using a warnings filter. Note that this has a perf impact for slicing a Series. ~25% slower

Master

```
In [9]: s = pd.Series(range(10000))

In [10]: %timeit s[:5]
43.5 µs ± 2.15 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [11]: t = pd.Series([], dtype=float)

In [12]: %timeit t[:]
47.8 µs ± 2.24 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
```

This PR

```
In [7]: s = pd.Series(range(10000))

In [8]: %timeit s[:5]
55.6 µs ± 1.69 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [9]: t = pd.Series([], dtype=float)

In [10]: %timeit t[:]
64.2 µs ± 2.27 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
```

Is that slowdown acceptable? Right now, I don't think it is, given that

1. This is just a DeprecationWarning
2. We'll be deprecating this in the future anyway.
I think there are 2 ways we get to get_slice with non-slice.  One of them is L931, and can be avoided be extracting the single-item list after potentially warning in #31333.  The other is on L940 and is explicltly  an "mpl hackaround", so we can maybe-unpack there.
Thanks @jbrockmendel, that did it. We're able to apply the filter only when using the mpl compat path.

master

```python
In [2]: s = pd.Series(range(10000))

In [3]: %timeit s[:, None]
36.2 µs ± 293 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [4]: t = pd.Series([], dtype=float)

In [5]: %timeit t[:]
52 µs ± 3.5 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [6]: %timeit s[:5]
45 µs ± 2.27 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
``` 



PR

```python
In [4]: s = pd.Series(range(10000))

In [5]: %timeit s[:, None]
50.2 µs ± 2.56 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [6]: t = pd.Series([], dtype=float)

In [7]: %timeit t[:]
48.4 µs ± 2 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [8]: %timeit s[:5]
44.3 µs ± 2.52 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
```

So the first case is the only one with a slowdown, which I think is acceptable given that we want to deprecate that behavior anyway.
Had to xfail a test asserting that this produced a warning. Will want to restore that with one from `Series.__getitem__` I think, but not for 1.0
> So the first case is the only one with a slowdown, which I think is acceptable given that we want to deprecate that behavior anyway.

Sounds good