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.

classification
Title: random.randrange completely ignores the step argument when stop is None
Type: Stage: resolved
Components: Library (Lib) Versions: Python 3.7, Python 3.6, Python 3.4, Python 3.5
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: bup, rhettinger, steven.daprano, tim.peters
Priority: normal Keywords: patch

Created on 2018-06-29 13:52 by bup, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 8010 closed bup, 2018-06-29 14:43
Messages (4)
msg320717 - (view) Author: Dan Snider (bup) * Date: 2018-06-29 13:52
This "bug" is present even in 2.7. I have a really hard time believing that, even if it would be incredibly rare for someone to stumble upon this, may others haven't noticed this rather glaring flaw in the code. I couldn't find any similar issues though. 

My idea of how conservative a standard library function should be may be skewed too far to right. So perhaps I'm mistaken that it's reasonable to assume `random.randrange(10, step=2)` should either:

* raise an error warning users that providing an alternate `step` value has no effect unless  `stop` is also provided;

* go ahead and allow it to work. Logically, the above function call is no different than `random.randrange(0, 10, 2)`.

While I have created a patch that allows alternate (positive) `step` values even if `stop` is `None`, I still think my first instinct is to say that it really should just behave like `range` by raising an error when `stop is None and step != 1`. In that way it emulates the fact `range` only takes positional arguments while keeping the performance boost the current signature has over an `*args` implementation.

I'll try to attach a PR to this after posting but I've never done this before. The patch also includes a simple but effective optimization which at the very least speeds the 1 argument form by 8.5% despite the extra `step==1` check, with the only "cost" of (rightfully, imo) ensuring that only integers are used.
msg320718 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2018-06-29 14:42
"I have a really hard time believing that [...] others haven't noticed this rather glaring flaw in the code."

*shrug* Easy or hard for you to believe, nevertheless this same quote-unquote "flaw" goes back to Python 1.5 or older. Whether that makes it a flaw, a bug or a feature, I don't know.

The documentation does say:

    "Keyword arguments should not be used because the 
    function may use them in unexpected ways."

https://docs.python.org/3/library/random.html#random.randrange

so I'd suggest that the behaviour of randrange(10, seed=2) is currently considered undefined.
msg320731 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-06-29 19:08
My vote is for "that's just the way it is, it works fine for just about everyone most of the time".  

In pure Python code, it is expensive to try to handle or defend against all possible input variations.
msg321065 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-07-04 22:23
Thank you for the contribution, but I'm going to decline.  The parallel function range() doesn't even accept keyword arguments.  I don't see any reason to support an oddity such as "randrange(10, step=2)" in part because the meaning isn't clear and in part because there is no known use case.
History
Date User Action Args
2022-04-11 14:59:02adminsetgithub: 78179
2018-07-04 22:23:28rhettingersetstatus: open -> closed
messages: + msg321065

assignee: tim.peters -> rhettinger
resolution: rejected
stage: patch review -> resolved
2018-06-29 19:08:36rhettingersetassignee: tim.peters

messages: + msg320731
nosy: + tim.peters
2018-06-29 14:43:32bupsetkeywords: + patch
stage: patch review
pull_requests: + pull_request7616
2018-06-29 14:42:52steven.dapranosetnosy: + rhettinger, steven.daprano
messages: + msg320718
2018-06-29 13:52:13bupcreate