This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients Arfrever, alex, barry, docs@python, eric.snow, mark.dickinson, mjacob, ncoghlan, python-dev, rhettinger, serhiy.storchaka, vstinner
Date 2019-06-03.06:46:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1559544414.65.0.445712205612.issue17576@roundup.psfhosted.org>
In-reply-to
Content
> Can we at least switch to PyLong_CheckExact?

+1

> I am not sure that converting to an exact int in low-level C API functions is the best option.

I am sure. :-)  The number of naturally-occurring cases where we're actually passing a subtype of `int` that's not exactly `int` should be tiny. So long as there's a PyLong_CheckExact fast path, I don't think there are really any performance concerns here.

And we definitely shouldn't let performance concerns dictate API; get the API right first, _then_ see what can be done about performance without changing the API. It's clear to me that `operator.index(obj)` _should_ give the exact same results as `obj.__index__()`.

I'll split my PR up into two pieces, one for turning the deprecated behaviour into TypeErrors, and a second one that just makes the PyLong_CheckExact change. (I likely won't have time before feature freeze, though. OTOH, the PyLong_CheckExact change could be considered a bugfix.)
History
Date User Action Args
2019-06-03 06:46:54mark.dickinsonsetrecipients: + mark.dickinson, barry, rhettinger, ncoghlan, vstinner, Arfrever, alex, docs@python, python-dev, eric.snow, serhiy.storchaka, mjacob
2019-06-03 06:46:54mark.dickinsonsetmessageid: <1559544414.65.0.445712205612.issue17576@roundup.psfhosted.org>
2019-06-03 06:46:54mark.dickinsonlinkissue17576 messages
2019-06-03 06:46:54mark.dickinsoncreate