[Python-Dev] PEP 506 secrets module (original) (raw)

Guido van Rossum guido at python.org
Sat Oct 17 19:05:42 EDT 2015

OK, so just randbelow() then.

--Guido (mobile) 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.

[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 arc4randomuniform() in OpenBSD - how do I spell that in secrets?". Answer: randbelow() is identical, except in Python the argument isn't limited to uint32t".

> 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... URL: <http://mail.python.org/pipermail/python-dev/attachments/20151017/9e422973/attachment.html>

More information about the Python-Dev mailing list