bpo-33998: randrange silently ignoring alt steps #8010
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
randrange currently and probably has always done nothing when provided with a non-default step value. There are two solutions: make the non-default step value actually have an effect on the potential results; or, cause it to throw an exception warning users that changing the value of step is pointless without providing an explicit stopping point.
While the first solution conflicts with the behavior of range, that isn't necessarily a bad thing. Since when the 2nd positional argument is omitted the first one already get reinterpreted as the stop point, it is illogical to not expect similar behavior when an alternate step value is provided via a keyword argument.
In addition, operator.index is 4-5x faster than the int constructor which leads to a significant performance boost. Since the code looks much cleaner, the comment about its hygiene can be removed
https://bugs.python.org/issue33998