Add random.sampleBuffer

[juancarlospaco]

• Add random.randToken.
• Inspired but not copied from Python 3.9+ secrets.token_urlsafe()
• ASCII by default.
• URL-Safe by default.
• Customizable length and set[char].
• Documentation with runnableExamples, since, changelog, tiny diff.
• Python generates a random string then calls base64 encode to make it URL safe, my implementation do not use base64.

Notes

• python3 -c "print(__import__('secrets').token_urlsafe())"
• https://www.reddit.com/r/nim/comments/le1ye9/how_can_i_create_a_function_to_return_random
• Add random.sampleBuffer #16957 (comment)

[juancarlospaco]

@timotheecour Can you review; thanks.

[juancarlospaco]

I agree, if you are a Nim core dev is very easy to implement, optimize and test, one more reason why it should be implemented,
new users often struggle with something is stdlib builtin and easy one-liner on Python:

• https://www.reddit.com/r/nim/comments/le1ye9/how_can_i_create_a_function_to_return_random
• More similar if you google it, but you get the idea...

:)

[timotheecour]

how about the following instead, which is more generic but not harder to use (compared a version of your PR that would add r: var Rand), and maintains separation of concern (std/random shouldn't deal with base64 encoding issues)

proc sampleBuffer*[T](r: var Rand, buffer: var openArray[T]; alphabet: set[T]) {.inline, since: (1, 5).} =
  runnableExamples:
    import sugar
    doAssert newString(8).dup(sampleBuffer(randState, _, {'0'..'9'})).len == 8
    import base64
    doAssert newString(8).dup(sampleBuffer(randState, _, cb64safe)).len == 8
  for c in buffer.mitems: c = sample(r, alphabet)

pros/cons:

• yes, it's easy to implement in one's code (but not as 1 liner)
• common enough, and this is something frequently asked in other languages, there's a library way or not
• doesn't add any meaningful complexity to std/random

[Clyybber]

how about the following instead, which is more generic but not harder to use (compared a version of your PR that would add r: var Rand), and maintains separation of concern (std/random shouldn't deal with base64 encoding issues)

proc sampleBuffer*[T](r: var Rand, buffer: var openArray[T]; alphabet: set[T]) {.inline, since: (1, 5).} =
  runnableExamples:
    import sugar
    doAssert newString(8).dup(sampleBuffer(randState, _, {'0'..'9'})).len == 8
    import base64
    doAssert newString(8).dup(sampleBuffer(randState, _, cb64safe)).len == 8
  for c in buffer.mitems: c = sample(r, alphabet)

pros/cons:

* yes, it's easy to implement in one's code (but not as 1 liner)

* common enough, and this is something frequently asked in other languages, there's a library way or not

* doesn't add any meaningful complexity to std/random

AFAICT your procs implementation is a one liner. The most complex part of this PR is the alphabet, so adding this makes even less sense IMO

[Araq]

I don't mind a Python inspired "secrets" module but random.nim isn't it:

Do not use this module for cryptographic purposes!

[juancarlospaco]

@Araq You dont like the proc ?, or you want it to be on a new module ?.

[Araq]

New module but ensure it's good enough for crypto.

[ringabout]

Just like the secrets module of Python, it should be based on system random
#16459

[timotheecour]

@xflywind how about instead keeping it in std/random, but changing randomize() to use the fresh new std/sysrandom, then users can choose depending on how they call:

# CSPRNG
var r = initRand(opt = useSysrand)
sampleBuffer(r, buf, alphabet)

# PRNG
var r = initRand(opt = useTime)
sampleBuffer(r, buf, alphabet)

# CSPRNG
randomize() # could be changed to: randState = initRand(opt = useSysrand)
sampleBuffer(randState, buf, alphabet) # uses default RNG