[Python-ideas] Pre-PEP Adding A Secrets Module To The Standard Library

[Paul Moore]

On 20 September 2015 at 00:40, Tim Peters <tim.peters at gmail.com> wrote:
> [Guido]
>> Thanks! I'd accept this (and I'd reject 504 at the same time). I like the
>> secrets name. I wonder though, should the PEP propose a specific set of
>> functions? (With the understanding that we might add more later.)
>
> The bikeshedding on that will be far more tedious than the
> implementation.  I'll get it started :-)
>
> No attempt to be minimal here.  More-than-less "obvious" is more important:
>
> Bound methods of a SystemRandom instance
>     .randrange()
>     .randint()
>     .randbits()
>         renamed from .getrandbits()
>     .randbelow(exclusive_upper_bound)
>         renamed from private ._randbelow()
>     .choice()
>
>  Token functions
>     .token_bytes(nbytes)
>         another name for os.urandom()
>     .token_hex(nbytes)
>         same, but return string of ASCII hex digits
>     .token_url(nbytes)
>         same, but return URL-safe base64-encoded ASCII
>     .token_alpha(alphabet, nchars)
>         string of `nchars` characters drawn uniformly
>         from `alphabet`

Given where this started, I'd suggest renaming token_alpha as
"password". Beginners wouldn't necessarily associate the term "token"
with the problem "I want to generate a random password" [1]. Maybe add
a short recipe showing how to meet constraints like "at least 2
digits" by simply generating repeatedly until a valid password is
found.

For a bit of extra bikeshedding, I'd make alphabet the second,
optional, parameter and default it to
string.ascii_letters+string.digits+string.punctuation, as that's often
what password constraints require.

Or at the very least, document how to use the module functions for the
common tasks we see people getting wrong. But I thought the idea here
was to make doing things the right way obvious, for people who don't
read documentation, so I'd prefer to see the functions exposed by the
module named based on the problems they solve, not on the features
they provide. (Even if that involves a little duplication, and/or a
split between "high level" and "low level" APIs).

Paul.

[1] I'd written a spec for password() before I spotted that it was the
same as token_alpha :-(