There's been no activity on this issue in a few months.... The three options as I see it are:

 1. Fix it for both randrange and SystemRandom.randrange, breaking randrange's implied stability between minor versions.
 2. Fix it only for SystemRandom.randrange.
 3. Close it as wont fix (for performance reasons I'd assume?).

Since I'm in favor of option 2, I've attached a simple patch which implements it. Here are some quick-and-dirty performance numbers showing the decrease in performance (3 tests of the original code followed by 3 of the patched code):

$ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**8' 's.randrange(r)'
10000 loops, best of 10: 22.5 usec per loop
$ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**31' 's.randrange(r)'
10000 loops, best of 10: 22.6 usec per loop
$ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**53 * 2//3' 's.randrange(r)'
10000 loops, best of 10: 22.4 usec per loop

$ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**8' 's.randrange(r)'
10000 loops, best of 10: 23.7 usec per loop
$ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**31' 's.randrange(r)'
10000 loops, best of 10: 46.2 usec per loop
$ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**53 * 2//3' 's.randrange(r)'
10000 loops, best of 10: 34.8 usec per loop

The patch also includes a unit test (with a false negative rate of 1 in 8.5 * 10^-8: http://www.wolframalpha.com/input/?i=probability+of+417+or+fewer+successes+in+1000+trials+with+p%3D0.5).

Any opinions on which of the three options should be taken?