Crytpo generators are a whole different world, and I wouldn't listen to anyone save a bona fide expert in that field.  Plausible:  the "hardest thing" OpenSSL has to do is generate secure RSA keys.  But the bit length of an RSA key can't be taken at face value:  the true strength of such a key is measured by the number of operations required to break it.  According to (among many others):

http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths

"NIST key management guidelines further suggest that 15360-bit RSA keys are equivalent in strength to 256-bit symmetric keys".

So 32 bytes = 256 bits of entropy is sufficient to generate secure 15360-bit RSA keys, which is larger than virtually anyone actually uses (so far), provided everything else is done exactly right.

For that reason, "bug reports" about OpenSSL using only 32 bytes seem to get brushed off, like:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742145

So what does that have to do with Python's random()?  Nothing ;-)

A more fruitful tack would be to investigate switching away from the Mersenne Twister.  It was groundbreaking at the time, but nothing lasts forever.  Even Wikipedia can come up with a list of its disadvantages now, including "the state space is too large and uselessly stresses the CPU cache":

http://en.wikipedia.org/wiki/Mersenne_twister#Disadvantages

Worse (according to me), when it reaches a point where "most of" the bits in its state are zeroes, it can take a long time (many calls) before its outputs pass randomness tests again - a paucity of 1 bits tends to persist "way too long".

More recent algorithms claim to address these flaws, with smaller state and similar speed.  But they're marginal improvements, and don't seem to be gaining traction quickly.  The Twister was a huge improvement at the time, and caught on very quickly.

In the meantime, better safe than sorry.