OK, so just randbelow() then. --Guido (mobile) On Oct 17, 2015 2:13 PM, "Tim Peters" <tim.pet...@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. > > [Guido] > > 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 > os.urandom()? > > 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 > :-) >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
