[Python-Dev] PEP 506 secrets module

[Guido van Rossum]

On Sat, Oct 17, 2015 at 2:50 AM, Steven D'Aprano <steve at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20151017/a8b4a1b7/attachment.html>