Re: [Python-Dev] PEP 506 secrets module

On Sat, Oct 17, 2015 at 2:50 AM, Steven D'Aprano <ste...@pearwood.info>
wrote:

> [...]> So you can see there is nothing even close to consensus as to which API> is best, which is an argument for keeping all three functions.>

No, that's not how we do it in Python. :-)


> But significanly, only *one* of the commenters has claimed to have any> significant experience in crypto work, and I will quote him:>>     Having done quite a bit of serious crypto implementation over the>     past 25 years, I don't recall ever wanting anything like randrange,>     and if I did need it, I'd probably build it inline from randbelow>     rather than force some hapless future code maintainer to look up the>     specs on randrange.>>     My opinion, FWIW: I like randbelow, because in modern crypto one>     very frequently works with integers in the range [0,M-1] for some>     large modulus M, and there is a constant risk of asking for>     something in [0,M] when one meant [0,M-1].  One can eliminate this>     risk, as randbelow does, by building in the -1, which normally>     introduces a risk of making a mistake that gives you [0,M-2], but>     the name "randbelow" seems like a neat fix to that problem.>>     -- Peter Pearson>

It's not clear whether this correspondent realizes that randrange(N) is
identical to randbelow(N).


> This matches what Serhiy suggests: in crypto, one normally only needs to> generate the half-open interval [0...n). It also matches the reason why> Tim Peters added randbelow in the first place.>> As the author of the PEP, I'm satisfied by this argument, and will now> state that my preferred option is to drop randint and randrange, and> just keep randbelow.>> My second choice is to keep all three functions.>> 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.

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

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