OK, so just randbelow() then.

--Guido (mobile)

On Oct 17, 2015 2:13 PM, "Tim Peters" <tim.peters@gmail.com> wrote:
[Steven D'Aprano]
>> ...
>> I think it is fair to say that out of the three functions, there is
>> consensus that randbelow has the most useful functionality in a crypto
>> context. Otherwise, people seem roughly equally split between the three
>> functions. There doesn't seem to be any use-case for the three argument
>> version of randrange.

> I'm fine with dropping the 3rd arg. But I find the argument to introduce a
> new spelling for 1-arg randrange() weak.

Note the inherent absurdity here ;-)  That is, we're proposing to add
a module _all_ of whose functions are merely trivial (to the educated)
respellings of functions that already exist elsewhere.  Is there,
e.g., really "a strong" argument for giving a different way to spell

That depends.  I'm playing along with the basic assumption:  that this
module intends to be as idiot-proof as possible.  In which case, sure,
rename away.

And in which case, no, randbelow is not a new spelling for 1-arg
randrange.  To the contrary, all the integer-like functions (including
randrange, randint, and choice) in the random module are currently
built on top of the private Random._randbelow() method.  The latter is
"the right" fundamental building block for implementing uniform choice
free of statistical bias.  It's also overwhelmingly most useful _on
its own_ in the `secrets` context, and has the crushing (to me, in
this context) advantage that its very name strongly suggests its
argument is not a possible return value.  Giving a strongly mnemonic
name to a function with a dead simple "one required integer argument"
signature is likely "as idiot-proof as possible" as it gets.

BTW, it also gives a simple answer to "I'm used to using
arc4random_uniform() in OpenBSD - how do I spell that in `secrets`?".
Answer:  `randbelow()` is identical, except in Python the argument
isn't limited to uint32_t".

> I definitely thing that randint() is an attractive nuisance so we should
> drop that.

`randrange()` isn't a nuisance at all in Python, but its signature is
more convoluted than putative users of the proposed module seem to
want, and long experience has shown its name is not idiot-proof.
`secrets` users aren't looking to pick something uniformly from "a
range" - they're looking to pick a non-negative integer less than some
upper bound.  Unneeded generalization beyond just that much is also an
attractive nuisance, in context.

"Simplest thing that can possibly suffice" is always a good way to start :-)