title: Equivalent to python's -R option that affects the hash of ints
body: <p>We have a large collection of python code that takes some input and produces some output.</p>
  
  <p>We would like to guarantee that, given the identical input, we produce identical output regardless of python version or local environment. (e.g. whether the code is run on Windows, Mac, or Linux, in 32-bit or 64-bit)</p>
  
  <p>We have been enforcing this in an automated test suite by running our program both with and without the <code>-R</code> option to python and comparing the output, assuming that would shake out any spots where our output accidentally wound up dependent on iteration over a <code>dict</code>. (The most common source of non-determinism in our code)</p>
  
  <p>However, as we recently adjusted our code to also support python 3, we discovered a place where our output depended in part on iteration over a <code>dict</code> that used <code>int</code>s as keys. This iteration order changed in python3 as compared to python2, and was making our output different. Our existing tests (all on python 2.7) didn't notice this. (Because <code>-R</code> doesn't affect the hash of <code>int</code>s) Once found, it was easy to fix, but we would like to have found it earlier.</p>
  
  <p>Is there any way to further stress-test our code and give us confidence that we've ferreted out all places where we end up implicitly depending on something that will possibly be different across python versions/environments? I think that something like <code>-R</code> or <code>PYTHONHASHSEED</code> that applied to numbers as well as to <code>str</code>, <code>bytes</code>, and <code>datetime</code> objects could work, but I'm open to other approaches. I would however like our automated test machine to need only a single python version installed, if possible.</p>
  
  <p>Another acceptable alternative would be some way to run our code with pypy tweaked so as to use a different order when iterating items out of a <code>dict</code>; I <em>think</em> our code runs on pypy, though it's not something we've ever explicitly supported. However, if some pypy expert gives us a way to tweak dictionary iteration order on different runs, it's something we'll work towards.</p>