Currently PyNumber_Index() can return something that's an instance of a strict subclass of int. For example PyNumber_Index(Py_True) returns Py_True. The same for operator.index():

>>> import operator
>>> operator.index(True)
True

The proposed PR makes it always return an int.

To avoid possible overhead for creating temporary integer object, added private function _PyNumber_Index() with the past behavior. It can be used for short-living integer objects which for which only its value will be used, but not its methods. For example in the implementation of PyLong_AsLong() and similar functions.

See also issue17576.

This change conflicts with the test added in issue26202. We perhaps should revert issue26202. This can also affect the user code which depends on range() attributes start, stop and step being instances of the int subclass.

The behaviour change for range sounds reasonable to me.

Just to make sure I understand the impact of the change:

- For Python < 3.10, we sometimes convert the range inputs to Python ints, and sometimes don't. For example, a start value of `np.int64(5)` would be converted, but a value of `True` would not be.

- With this change, we'd always convert a non-int to an int, so both `np.int64(1)` and `True` would be converted to a `1` of exact type int.

IMO this is fine; the new behaviour seems more consistent than the old.

>>> import numpy as np
>>> start = np.int64(2)
>>> range(start, 5).start is start
False
>>> start = True
>>> range(start, 5).start is start
True

New changeset 5f4b229df7812f1788287095eb6b138bb21876a4 by Serhiy Storchaka in branch 'master':
bpo-40792: Make the result of PyNumber_Index() always having exact type int. (GH-20443)
https://github.com/python/cpython/commit/5f4b229df7812f1788287095eb6b138bb21876a4