classification
Title: Modernize integer test/conversion in randrange()
Type: Stage: resolved
Components: Library (Lib) Versions: Python 3.10
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: rhettinger, serhiy.storchaka, terry.reedy, tim.peters, veky
Priority: normal Keywords: patch

Created on 2020-10-31 17:27 by rhettinger, last changed 2021-10-15 16:17 by rhettinger. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 23064 merged rhettinger, 2020-10-31 17:27
PR 28983 open rhettinger, 2021-10-15 16:17
Messages (13)
msg380082 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-10-31 17:27
Move the int(x)==x test and conversion into the C code for operator.index().
msg380083 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-10-31 17:34
And, if we were willing to correct the exception type from ValueError to TypeError, the code could be made simpler, faster, and more in line with user expectations.
msg380084 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-10-31 17:54
I had forgotten. It looks like float arguments were allowed:

    >>> randrange(10.0, 20.0, 2.0)
    16

Is this worth going through a deprecation cycle to get the code cleaned-up or should we live with it as is?
msg380085 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-10-31 18:09
It changes the behavior. Currently randrange(10.0) works, but with PR 23064 it would fail.

See issue40046 with a ready PR for increasing coverage for the random module. If it would accepted, some tests would fail with PR 23064.

If you want to deprecate accepting float arguments, there was issue40046 with a ready PR.

These propositions were rejected by you. Have you reconsidered your decision?
msg380086 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-10-31 18:19
> These propositions were rejected by you. 
> Have you reconsidered your decision?

I was reluctant to break any existing code.
Now, I'm unsure and am inclined to harmonize it with range().

What do you think?
Should we have ever supported float arguments
for an integer domain function?
msg380089 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-10-31 19:03
I think and always thought that integer domain functions should not accept non-integer arguments even with integer value. This is why I submitted numerous patches for deprecating and finally removing support of non-integer arguments in most of integer domain functions. C implemented functions which use PyArg_Parse("i") or PyLong_AsLong() for parsing arguments use now index() instead of int(). They emit a deprecation warning for non-integers in 3.8 and 3.9 and raise type error since 3.10. math.factorial() emits a warning only in 3.9.

Issue37319 (sorry, I wrote incorrect issue number in msg380085) was initially opened for 3.9, so we could convert warnings into errors in 3.10 or 3.11.

Currently randrange(1e25) can return value larger than 10**25, because int(1e25) == 10000000000000000905969664 > 10**25.
msg380096 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-10-31 20:25
User feedback concur with making the change:  https://twitter.com/raymondh/status/1322607969754775552
msg380099 - (view) Author: Vedran Čačić (veky) * Date: 2020-10-31 21:11
Yes, the ability to write randrange(1e9) is sometimes nice. And the fact that it might give the number outside the intended range with probability 1e-17 is not really an important argument (people have bad intuitions about very small probabilities). But if we intend to be consistent with range, then of course this must go.
msg380111 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-11-01 01:39
10**9 isn't much harder than 10E9 ;-)
msg380498 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-11-07 10:00
To me, ValueError("non-integer arg 1 for randrange()") (ValueError('bad type') is a bit painful to read.  We do sometime fix such bugs, when not documented, in future releases.

Current the doc, "Return a randomly selected element from range(start, stop, step). This is equivalent to choice(range(start, stop, step))", implies that both accept the same values, which most would expect anyway from the names.  Being selectively 'generous' in what is accepted is confusing.

For the future: both range and math.factorial raise
TypeError: 'float' object cannot be interpreted as an integer
The consistency is nice.  randrange should say the same after deprecation.
msg380499 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-11-07 10:11
To put what I said another way: both items are mental paper cuts and I see benefit to both coredevs and users in getting rid of them.  That is not to say 'no cost', but that there is a real benefit to be balanced against the real cost.
msg383776 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-12-25 22:38
There is another randrange() oddity.  If stop is None, the step argument is ignored:

    >>> randrange(100, stop=None, step=10)
    4

If we want to fully harmonize with range(), then randrange() should only accept positional arguments and should not allow None for the stop argument.  That would leave the unoptimized implementation equivalent to:

    def randrange(self, /, *args):
        return self.choice(range(*args))

The actual implementation can retain its fast paths and have a nicer looking signature perhaps using __text_signature__.
msg383916 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-12-28 19:10
New changeset a9621bb301dba44494e81edc00e3a3b62c96af26 by Raymond Hettinger in branch 'master':
bpo-42222: Modernize integer test/conversion in randrange() (#23064)
https://github.com/python/cpython/commit/a9621bb301dba44494e81edc00e3a3b62c96af26
History
Date User Action Args
2021-10-15 16:17:44rhettingersetpull_requests: + pull_request27270
2020-12-28 19:11:34rhettingersetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2020-12-28 19:10:53rhettingersetmessages: + msg383916
2020-12-25 22:38:51rhettingersetmessages: + msg383776
2020-12-24 09:18:46rhettingersetassignee: rhettinger
2020-11-07 10:11:45terry.reedysetmessages: + msg380499
2020-11-07 10:00:59terry.reedysetnosy: + terry.reedy
messages: + msg380498
2020-11-01 01:39:33rhettingersetmessages: + msg380111
2020-10-31 21:11:58vekysetnosy: + veky
messages: + msg380099
2020-10-31 20:25:04rhettingersetmessages: + msg380096
2020-10-31 19:03:18serhiy.storchakasetmessages: + msg380089
2020-10-31 18:19:03rhettingersetmessages: + msg380086
2020-10-31 18:09:28serhiy.storchakasetmessages: + msg380085
2020-10-31 17:54:30rhettingersetmessages: + msg380084
2020-10-31 17:34:52rhettingersetmessages: + msg380083
2020-10-31 17:27:39rhettingersetkeywords: + patch
stage: patch review
pull_requests: + pull_request21983
2020-10-31 17:27:12rhettingercreate