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.

"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.

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.

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.

assignee: tim.peters -> rhettinger
resolution: rejected
stage: patch review -> resolved

messages: + msg320731
nosy: + tim.peters