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')

How random would be the 0 returned by getrandbits(0)? :-)

I think you know the answer to your question ;-)

Seconded.

And I wish to add the getrandbytes() method.

This was discussed previously in bpo-37000.

I agree that getrandbits(0) should succeed.

+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.

I do not want to open an issue if I know that the idea will be rejected.

About a hypothetical getrandbytes(), probably 90% of my uses of getrandbits() have been to generate random bytestrings.

Why not use secrets.token_bytes() or randrange(2**b).to_bytes()? Do you really need an API extension?

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.

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".

I created bpo-40286: Add getrandbytes() method to random.Random.

New changeset 75a3378 by Antoine Pitrou in branch 'master':
bpo-40282: Allow random.getrandbits(0) (GH-19539)
75a3378