[Python-Dev] os.urandom API

["Martin v. Löwis"]

Raymond Hettinger wrote:
> I would like to change the API for the new os.urandom(n) function to
> return a long integer instead of a string.  The former better serves
> more use cases and fits better with existing modules.

-1. Bytes is what the underlying system returns, and it is also
conceptually the right thing. We are really talking about a stream
of random bytes here (where u signals unlimitedness).

> 1) The call random.seed(os.random(100)) is a likely use case.  If the
> intermediate value is a string, then random.seed() will hash it and only
> use 32 bits.  If the intermediate value is a long integer, all bits are
> used.  In the given example, the latter is clearly what the user expects
> (otherwise, they would only request 4 bytes).

Then add an os.randint if you think this is important. Given the
easiness of using the struct module, I don't think it is important to
provide this out of the box.

> 2) Another likely use case is accessing all the tools in the random
> module with a subclass that overrides random() and getrandbits().  Both
> can be done easier and faster if os.random() returns long integers.  If
> the starting point is a string, the code gets ugly and slow.

Don't try guessing use cases too much. I don't think either the original
submitter, nor the original reviewer, had sequences of pseudo-random
numbers as their use case. Instead, the typical application will be a
one-time token for some crypto algorithm, in which case sequences of
pseudo-randomness are evil. What kind of data structure these things
will need is hard to guess, but "sequence of bytes" is a good bet.

> 3) Most use cases for random values involve numeric manipulation.
> Simple tasks like finding a random integer in the range [0,100000)
> become unnecessarily more complicated when starting from a string.

That is not true. Most use cases of random numbers involve bit
manipulation.

> 1) This form is handy for cyptoweenies to xor with other byte strings
> (perhaps for a one-time pad).

And indeed, cryptoweenies have contributed that code. He who writes
the code choses the interface.

Regards,
Martin