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.