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

Serhiy Storchaka storchaka at gmail.com
Mon Sep 21 22:12:28 CEST 2015


On 21.09.15 19:22, Steven D'Aprano wrote:
> On Sun, Sep 20, 2015 at 09:00:08AM +0300, Serhiy Storchaka wrote:
>> On 20.09.15 02:40, Tim Peters wrote:
>>> 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()
>>
>> randbelow() is just an alias for randrange() with single argument.
>> randint(a, b) == randrange(a, b+1).
>>
>> These functions are redundant and they have non-zero cost.
>
> But they already exist in the random module, so adding them to secrets
> doesn't cost anything extra.

The main cost is learning and memorising cost. The fewer words you need 
to learn and keep in memory the better.

>> Would not renaming getrandbits be confused?
>>
>>>   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`
>>
>> token_hex(nbytes) == token_alpha('0123456789abcdef', nchars) ?
>> token_url(nbytes) == token_alpha(
>>      'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_',
>>       nchars) ?
>
> They may be reasonable implementations for the functions, but simple as
> they are, I think we still want to provide them as named functions
> rather than expect the user to write things like the above. If they're
> doing it more than once, they'll want to write a helper function, we
> might as well provide that for them.

But why these particular alphabets are special? I expect that every 
application will use the alphabet that matches its needs. One needs 
decimal digits ('0123456789'), other needs English letters 
('ABCDEFGHIJKLMNOPQRSTUVWXYZ'), or letters and digits and underscore, or 
letters, digits and punctuation, or all safe ASCII characters, or  all 
well graphical distinguished characters. Why token_hex and token_url, 
but not token_digits, token_letters, token_identifier, token_base32, 
token_base85, token_html_safe, etc?



More information about the Python-ideas mailing list