This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients mark.dickinson, pitrou, rhettinger, serhiy.storchaka, steven.daprano, tim.peters, vstinner
Date 2020-04-14.21:46:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1586900768.94.0.399896427183.issue40282@roundup.psfhosted.org>
In-reply-to
Content
> That is feature creep and no user has requested it.

Python already provides such function in the secrets module, so I'm not sure if what you mean that "no users has requested it". secrets.token_bytes() exists because there is a need for such function.

secrets.token_bytes() is more designed for security, but random.Random() is more designed for simulations. And such users also exists, that's why numpy provides numpy.random.bytes(length) function:
https://docs.scipy.org/doc/numpy-1.15.0/reference/generated/numpy.random.bytes.html

To be honest, I never understood where there is such "hole" in the random module API. Especially for SystemRandom since its source os.urandom() generates bytes.

A concrete use case is to generate manually a UUID4 from 16 random bytes. For testing, you may want to get "deterministic random" UUID4. Using getrandbits() for thta sounds unnatural to me. 

Another use case is to create a secret token: well, that's basically that secrets.token_bytes() does. That's used in multiprocessing but also in urllib (AbstractDigestAuthHandler.get_cnonce()).

So yeah, it sounds perfectly reasonable to add such simple function. I don't see how add such obvious function would be a "feature creep".
History
Date User Action Args
2020-04-14 21:46:08vstinnersetrecipients: + vstinner, tim.peters, rhettinger, mark.dickinson, pitrou, steven.daprano, serhiy.storchaka
2020-04-14 21:46:08vstinnersetmessageid: <1586900768.94.0.399896427183.issue40282@roundup.psfhosted.org>
2020-04-14 21:46:08vstinnerlinkissue40282 messages
2020-04-14 21:46:08vstinnercreate