classification
Title: random.getrandbits(0) should succeed
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.9
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: mark.dickinson, pitrou, rhettinger, serhiy.storchaka, steven.daprano, tim.peters, vstinner
Priority: normal Keywords: patch

Created on 2020-04-14 15:32 by pitrou, last changed 2020-04-17 17:32 by pitrou. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 19539 merged pitrou, 2020-04-15 08:24
Messages (13)
msg366392 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2020-04-14 15:32
When creating variable-sized random binary strings with random.getrandbits(), you currently have to special case when the number of bytes is 0, because otherwise getrandbits() raises:

  ValueError: number of bits must be greater than zero

It seems like it wouldn't hurt to simply return 0 in that case.

The actual snippet looks something like:

  random.getrandombits(nbytes * 8).to_bytes(nbytes, 'little')
msg366393 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-04-14 15:33
How random would be the 0 returned by getrandbits(0)? :-)
msg366394 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2020-04-14 15:37
I think you know the answer to your question ;-)
msg366429 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-04-14 18:43
Seconded.

And I wish to add the getrandbytes() method.
msg366430 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2020-04-14 18:52
This was discussed previously in #37000.

I agree that `getrandbits(0)` should succeed.
msg366440 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-04-14 20:03
+0 for having getrandbits(0) return 0.  Conceptually, it is reasonable.  Practically, it is a bit inconvenient because the ValueError may have to be moved upstream to the _randbelow() methods.

-1 for getrandbytes().  That is feature creep and no user has requested it.  Also, the name leads to a confusing API with getrandbits() returning arbitrary sized python ints and getrandbytes() returning bytes.  Lastly, it mostly duplicates functionality already supplied by secrets.token_bytes().  If you really want this, open another tracker issue and don't derail the issue at hand.
msg366443 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-04-14 20:50
I do not want to open an issue if I know that the idea will be rejected.
msg366444 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2020-04-14 20:51
About a hypothetical getrandbytes(), probably 90% of my uses of getrandbits() have been to generate random bytestrings.
msg366445 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-04-14 21:01
Why not use secrets.token_bytes() or randrange(2**b).to_bytes()?   Do you really need an API extension?
msg366446 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2020-04-14 21:04
I agree I don't *need* it per se.  However, I suspect that for non-exports it would be easier than
`getrandbits(nbytes * 8).to_bytes(nbytes, 'endian')`.

As for `secrets.token_bytes()`, it's not really adequate for regular pseudo-random data generation when you want to use a fixed seed.  And I'm not sure what its performance characteristics are when you pass a large size.
msg366452 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-04-14 21:46
> 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".
msg366455 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-04-14 22:41
I created bpo-40286: Add getrandbytes() method to random.Random.
msg366670 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2020-04-17 17:32
New changeset 75a3378810bab03949ad9f653f78d933bdf3879c by Antoine Pitrou in branch 'master':
bpo-40282: Allow random.getrandbits(0) (GH-19539)
https://github.com/python/cpython/commit/75a3378810bab03949ad9f653f78d933bdf3879c
History
Date User Action Args
2020-04-17 17:32:30pitrousetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2020-04-17 17:32:20pitrousetmessages: + msg366670
2020-04-15 08:24:37pitrousetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request18887
2020-04-14 22:41:39vstinnersetmessages: + msg366455
2020-04-14 21:46:08vstinnersetmessages: + msg366452
2020-04-14 21:04:50pitrousetmessages: + msg366446
2020-04-14 21:01:50rhettingersetnosy: + tim.peters
messages: + msg366445
2020-04-14 20:52:22pitrousetcomponents: + Library (Lib)
2020-04-14 20:52:16pitrousetstage: needs patch
2020-04-14 20:51:04pitrousetmessages: + msg366444
2020-04-14 20:50:03serhiy.storchakasetmessages: + msg366443
2020-04-14 20:03:51rhettingersetmessages: + msg366440
2020-04-14 18:52:43mark.dickinsonsetmessages: + msg366430
2020-04-14 18:43:49serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg366429
2020-04-14 15:37:45pitrousetmessages: + msg366394
2020-04-14 15:33:46vstinnersetnosy: + vstinner
messages: + msg366393
2020-04-14 15:32:35pitroucreate