Single-argument randrange(n) is the same as randbelow(n), right? I don't see any reason to have randbelow() if that's true.

On Fri, Oct 16, 2015 at 11:29 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
On 16.10.15 19:26, Steven D'Aprano wrote:
On Fri, Oct 16, 2015 at 06:35:14PM +0300, Serhiy Storchaka wrote:
I suggest to add only randrange(). randint() is historical artefact, we
shouldn't repeat this mistake in new module. The secrets module is not
good way to generate dice rolls. In most other cases you need to
generate integers in half-open interval [0; N).

And randbelow() is absolute redundant. Random._randbelow() is
implementation detail and I inclined to get rid of it (implementing
randrange() in C instead).

This was discussed on Python-Ideas, and there was little consensus there
either. (Looks like Tim Peters' prediction is coming true :-)

Putting aside your inflammatory description of randint() as a "mistake",
if you are correct that in most cases people will need to generate
integers in the half-open interval [0...n) then we should keep
randbelow, since that is precisely what it does.

Andrew explained the history of the issue (http://permalink.gmane.org/gmane.comp.python.ideas/36437). randrange was added in 61464037da53 to address a problem with unpythonic randint.

Personally, I have no sense of which of the three functions will be most
useful, but if you are right about the half-open [0...n) interval, then
randbelow seems to be the right API to offer. But I have seen people
argue in favour of randint, and others argue in favour of randrange.
Given that these are just thin wrappers or aliases to methods of
random.SystemRandom, I don't think there is any harm in providing all
three.

Yes, randbelow provides simpler API, but randrange is more familiar for Python users due to similarity to range and because it is the public API in the random module (unlike to randbelow).



--
--Guido van Rossum (python.org/~guido)