DEPR: Remove NumericIndex from pandas/_testing/

[topper-123]

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.

[jbrockmendel]

(type(index) is Index and index.dtype == "int64") is True

isn't there a keyword for this?

[mroeschke]

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

[topper-123]

(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.

[jbrockmendel]

In assert_index_equal we have 'exact' for allowing an Int64Index to be close enough to a RangeIndex. That can't be repurposed?

[topper-123]

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:

>>> 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?

[topper-123]

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.

[jbrockmendel]

without a keyword, assert_foo_equal should require dtypes to match

[topper-123]

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.

[jbrockmendel]

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

[mroeschke]

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")

[jbrockmendel]

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)

[topper-123]

Yeah, I agree with @jbrockmendel on this.

[topper-123]

Yeah, I agree with @jbrockmendel on this.

[mroeschke]

Okay that's fair; my opinion isn't super strong (FWIW I'm not super fond of having exact="equiv" in the first place)

[jbrockmendel]

so are we good to merge?

[mroeschke]

LGTM

[mroeschke]

Thanks @topper-123