DEPR: Remove NumericIndex from pandas/_testing/
State: closed

Removes `NumericIndex` from `pandas._testing`.

A decision has to be made how `assert_index_equal` should interpret equivalence between an index and a `RangeIndex`. IMO two indexes should be equivalent if they both return true for one of the two tests below:
1.  isinstance(index, RangeIndex) is True, or
2. (type(index) is Index and index.dtype == "int64") is True

The first is easy to agree on, but notice that the second means that an `Index` subclass with int64 dtype will not be equivalent to a `RangeIndex`. My thinking is that if the user subclasses `Index`, then subclass instances shouldn't be equivalent to `RangeIndex`, even if it has a int64 dtype.

Also, int32/int16/int8 indexes won't be equivalent to `RangeIndex` in this implementation.


Labels:
name: Deprecate
description: Functionality to remove in pandas
name: Index
description: Related to the Index class or subclasses

Comments:
`(type(index) is Index and index.dtype == "int64") is True`

isn't there a keyword for this?


IMO I think int32/int16/int8 indexes should probably be considered equal to RangeIndex if the values appear equivalent, but probably better discussed & maybe addressed in a follow up
> `(type(index) is Index and index.dtype == "int64") is True`
> 
> isn't there a keyword for this?

I don't think so. There is `is_int64_dtype`, but that only checks for it being array-like. Also (in my proposal), we check `type(index)` (not `isinstance(index, Index)`) and I don't think that check exists.
In assert_index_equal we have 'exact' for allowing an Int64Index to be close enough to a RangeIndex.  That can't be repurposed?
> IMO I think int32/int16/int8 indexes should probably be considered equal to RangeIndex if the values appear equivalent, but probably better discussed & maybe addressed in a follow up

ATM we have:

```python
>>> x1 = pd.Index([1, 2, 3], dtype="int8")
>>> x2 = pd.Index([1, 2, 3], dtype="int32")
>>> tm.assert_index_equal(x1, x2)
AssertionError: Index are different

Attribute "dtype" are different
[left]:  int32
[right]: int8
```

If your suggestion should be implemented, the above assertion should also be able to pass IMO, do we want that? Then what about `Series` with int8 and int32, should we have a mechanism where they can pass also?

> In assert_index_equal we have 'exact' for allowing an Int64Index to be close enough to a RangeIndex. That can't be repurposed?

I'm not sure I understand you here, could you expand? This is about the functionality of `assert_index_equal` and the `exact` parameter, as I see it.
without a keyword, assert_foo_equal should require dtypes to match
A new keyword or an added option to `exact`? That should be for another PR IMO.

As an aside, I would like the default value for `exact` to be `True`, not `"equiv"`. I think most of the time when testing, you want as precise testing by default as possible, and then you could relax the test as needed , by changing parameters.

> A new keyword or an added option to exact? That should be for another PR IMO.

Definitely not a new keyword.  I was mostly just observing that the "exact" keyword was intended to allow case 2 from the OP to be equal-enough for assert_index_equal.

> As an aside, I would like the default value for exact to be True, not "equiv". I think most of the time when testing, you want as precise testing by default as possible, and then you could relax the test as needed , by changing parameters.

+1
Yeah I would expect

```
# Passes
tm.assert_index_equal(Index([1, 2, 3]], dtype=np.int64), RangeIndex(1, 4), exact="equiv")

# Passes in the future
tm.assert_index_equal(Index([1, 2, 3]], dtype=np.int16), RangeIndex(1, 4), exact="equiv")

# Raises
tm.assert_index_equal(Index([1, 2, 3]], dtype=np.int16), Index([1, 2, 3]], dtype=np.int32), exact="equiv")
```
I (and I think topper) disagree with mroeschke on the Index[int16]-vs-RangeIndex case.  I think we should be maximally-strict and have that raise.

(if down the line the default for 'exact' is changed from "equiv" to True, then id be open to allowing that to not-raise)
Yeah, I agree with @jbrockmendel on this.
Yeah, I agree with @jbrockmendel on this.
Okay that's fair; my opinion isn't super strong (FWIW I'm not super fond of having `exact="equiv"` in the first place)
so are we good to merge?
Thanks @topper-123