Further suggestions to improve the random module:

** Object-oriented PRNG: Let it be an object which stores the random state internally, so we can create independent PRNG objects. I.e. not just one global generator.

** Generator for quasi-random Sobol sequences.  These fail most statistical tests for randomness. But for many practical uses of random numbers, e.g. simulations and numerical integration, convergence can be orders of magnitude faster (often 1000x faster convergence) but still numerically correct. That is, they are not designed to "look random", but fill the sample space as uniformly as possible.

** For cryptographically strong random numbers, os.urandom is a good back-end. It will use /dev/urandom on Linux and CryptGenRandom on Windows.  We still e.g. need a method to convert random bits from os.urandom to floats with given distributions. os.urandom is already in the standard library, so there is no reason the random module should not use it.

** Ziggurat method for generating normal, exponential and gamma deviates. This avoids most call to trancendental functions (sin, cos, log) in transforming from uniform random deviates, and is thus much faster.

** Option to return a buffer (bytearray?) with random numbers. Some times we don't need Python ints or floats, but rather the raw bytes.

** Support for more statistical distributions. Provide a much broader coverage than today. 

** Markov Chain Monte Carlo (MCMC) generator. Provide simple plug-in factories for the Gibbs sampler and the Metropolis-Hastings alorithm.