Having SystemRandom() use less memory is nice.  The seed() logic is reusable (not MT specific) and should be kept.  Historically, subclassers were supposed to supply random(), and the getrandbits() method was optional and just added greater range to randrange.  Am not sure I'm comfortable with you defining random() in pure python dividing by BPF -- that seems like a C level decision. Perhaps some factoring may be useful, but I worry that you're changing the user contracts in subtle ways and that we aren't really gaining anything out of this.  I'll just wait to see what everyone else has to say.  For me, I really wish you wouldn't do this and would have instead just added randbytes() in a way that was in harmony with the rest of the module.  I am getting afraid to submit bug reports because instead of fixing them, it triggers broad redesign and churn.  This all started because Antoine and Mark wanted getrandbits(0) to return 0; that was such a minor thing, and now the code is experiencing instability and is in some places measurably slower.

> The base class should implement randbytes() using getrandbits()

That is a reimagining of the API at odds with the 20+ year history of the module.  If we were starting out from scratch, that might have been a reasonable path, but with long standing, stable code, it doesn't make as much sense.