[Python-Dev] PEP 506 secrets module
Guido van Rossum
guido at python.org
Sat Oct 17 19:05:42 EDT 2015
OK, so just randbelow() then.
On Oct 17, 2015 2:13 PM, "Tim Peters" <tim.peters at 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev