Message344384
| 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:54 | mark.dickinson | set | recipients:
+ mark.dickinson, barry, rhettinger, ncoghlan, vstinner, Arfrever, alex, docs@python, python-dev, eric.snow, serhiy.storchaka, mjacob |
| 2019年06月03日 06:46:54 | mark.dickinson | set | messageid: <1559544414.65.0.445712205612.issue17576@roundup.psfhosted.org> |
| 2019年06月03日 06:46:54 | mark.dickinson | link | issue17576 messages |
| 2019年06月03日 06:46:54 | mark.dickinson | create |
|