Repository navigation
Make PyNumber_Index() always returning an exact int instance #84969
Description
| BPO | 40792 |
|---|---|
| Nosy | @warsaw, @mdickinson, @serhiy-storchaka |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2020-05-28.07:36:23.218>
created_at = <Date 2020-05-27.07:57:47.257>
labels = ['interpreter-core', 'type-feature', '3.10']
title = 'Make PyNumber_Index() always returning an exact int instance'
updated_at = <Date 2020-05-28.07:36:23.217>
user = 'https://github.com/serhiy-storchaka'bugs.python.org fields:
activity = <Date 2020-05-28.07:36:23.217>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2020-05-28.07:36:23.218>
closer = 'serhiy.storchaka'
components = ['Interpreter Core']
creation = <Date 2020-05-27.07:57:47.257>
creator = 'serhiy.storchaka'
dependencies = []
files = []
hgrepos = []
issue_num = 40792
keywords = ['patch']
message_count = 4.0
messages = ['370054', '370064', '370071', '370168']
nosy_count = 3.0
nosy_names = ['barry', 'mark.dickinson', 'serhiy.storchaka']
pr_nums = ['20443']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue40792'
versions = ['Python 3.10']
Activity
serhiy-storchaka commentedon May 27, 2020
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():
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 bpo-17576.
serhiy-storchaka commentedon May 27, 2020
This change conflicts with the test added in bpo-26202. We perhaps should revert bpo-26202. This can also affect the user code which depends on range() attributes start, stop and step being instances of the int subclass.
mdickinson commentedon May 27, 2020
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 ofTruewould not be.With this change, we'd always convert a non-int to an int, so both
np.int64(1)andTruewould be converted to a1of exact type int.IMO this is fine; the new behaviour seems more consistent than the old.
serhiy-storchaka commentedon May 28, 2020
New changeset 5f4b229 by Serhiy Storchaka in branch 'master':
bpo-40792: Make the result of PyNumber_Index() always having exact type int. (GH-20443)
5f4b229