On 21.09.15 19:29, Robert Kern wrote:
On 2015-09-21 17: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:
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.
Actually, I don't think those are the semantics that Tim intended. Rather, token_hex(nbytes) would return a string twice as long as nbytes. The idea is that you want to get nbytes-worth of random bits, just encoded in a common "safe" format. Similarly, token_url(nbytes) would get nbytes of random bits then base64-encode it, not just pick nbytes characters from a URL-safe list of characters. This makes it easier to reason about how much entropy you are actually using.
Looks as the semantic of these functions is not so obvious. May be add generic function that encodes a sequence of bytes with specified alphabet?