I did not notice the existence of random.SystemRandom until after I had
implemented my own version. I thought it would be nice to mention it in
the opening section. I've added a tiny note about random.SystemRandom.
What do you guys think, feel free to reword it, I just think that it
should be mentioned.

http://docs.python.org/library/random.html

I think non-determinism is more then os.urandom can deliver. As far as I 
know the OS still does deterministic calculations, though they are maybe 
less obvious. Maybe call it "safer, OS dependent"?

FWIW, the docs for os.urandom() state:

"""Return a string of n random bytes suitable for cryptographic use.

This function returns random bytes from an OS-specific randomness
source. The returned data should be unpredictable enough for
cryptographic applications, though its exact quality depends on the OS
implementation. On a UNIX-like system this will query /dev/urandom, and
on Windows it will use CryptGenRandom.
"""

Oh, urandom is almost always non-deterministic. It mixes completely
random bits from hardware sources with its pseudo-random number state.
The more random bits it gets from hardware, the less predictable its
output is. However, as long as it's getting any random bits, it's output
is not deterministic (because it's based on some random information).

But perhaps there is better wording that conveys the power of the
urandom source?

Maybe os.urandom is "more random" than the module random in the sense that 
it is harder to figure out what comes next, but still deterministic. The 
readings from the hardware are random and you usually don't know them, yet 
what comes out of urandom is determined by what urandom reads from the 
hardware and its state. I just want to warn not to drop wrong terms.

Ah, sorry for the misunderstanding. I agree, better not to mislead. 

Perhaps we should side with the urandom documentation and say that it is
a cryptographically secure random number generator with no accessible state?

Depends on how verbose we want to be. It should say why one might want to 
use urandom() instead of random (if you decide you are interested you can 
still look up the documentation). I think it would be nice to say why 
random does not use urandom if urandom is better, so you end up with a 
very short pro/con of urandom, which should be appropriate for users who 
are seeking information on getting random numbers.

Unfortunately I don't know enough about random. I guess it's a 
speed/security tradeoff?

A major pro for pseudo-random number generators is that they are
deterministic, that is, you can save a load the state, start from the
same seed and reproduce results, etc. At least in science (and probably
other areas) this reproducibility can be vital in a random class.

It really depends on your application though. In my use, I was
originally using normal random to produce seeds for another programs
random number generator. This ended up producing many identical results
and thus not producing an appropriate random sampling. Rather than
trying to figure out a proper way to do this with a PRNG I decided to
just use a completely random source, urandom was close enough for my needs.

I believe that is its strongest value, not having the strange artifacts
that PRNGs have. But I'm not completely sure how true that claim is :)

I rewrote the description, mostly using the claims form urandom, so that
we don't claim something new. What do you guys think?

The wording looks reasonable but it doesn't seem to add much that is not
already said:

'''
class SystemRandom( [seed]) 

Class that uses the os.urandom() function for generating random numbers
from sources provided by the operating system. Not available on all
systems. Does not rely on software state and sequences are not
reproducible. Accordingly, the seed() and jumpahead() methods have no
effect and are ignored. The getstate() and setstate() methods raise
NotImplementedError if called. 
'''

I hesitate to include anything about cryptographic strength because that
isn't really guaranteed on any system.  At best, there are a fixed
number of bytes of machine generated entropy.  At worst, it is
deterministic (computed from time, etc) or it is not available at all.

So, all I really want to do is call attention to SystemRandom from the
top of the page, because it is easily not noticed at the bottom. Do you
guys have any suggestions for how to do that that doesn't repeat too
much and doesn't claim things that you aren't comfortable with claiming?

How about this, sweet and simple.

I'm disinclined to move this to the top of the page but will keep this
open and consider further at a later date.

The SystemRandom class is an alternative generator like WichmanHill
which is typically not the right choice for many applications.

There is a whole paragraph about WichmanHill at the top of this page
already and (if anything) I think that WichmanHill is less notable
(basically only used in legacy applications). However SystemRandom is
very useful. I don't want to make claims about urandom that I can't back
up, but urandom is very useful and I think that there ought to be some
note of it in the opening for people who want a stronger random
instance. All I'm suggesting is a sentence to point it out. That would
have been enough for me not to have reinvented the wheel.

I think many people who are looking for a random number generator end up 
on this page and need to be informed if there are alternatives so they can 
make up their own mind. If you want to discourage people to use it, that's 
fine and we can do so, but I think it's wrong to hide it from people who 
don't suspect random functions which are os dependent to be in the os 
package instead of the random package or don't even know about the os 
random facility.

ping

Please look at the last patch. It's very simple and would be helpful. This is not very complicated and shouldn't take months to consider.

I recall an experience with a random file in /dev that was considerably slow after consuming its cache.  I used it as a seeder.  I've now got an ubuntu system for which /dev/urandom gives me a hundred million bytes quickly.  Perhaps a nosy one has more information?

ping

Committed to 2.7 as r78297. I modified the patch yet further, just describing the SystemRandom class and leaving the versionchanged text
about MersenneTwister/Wichman-Hill where it was, though I edited it
to be clearer.