On Sat, 2012-01-28 at 20:05 +0000, Benjamin Peterson wrote: > Benjamin Peterson <benjamin@python.org> added the comment: > > I think we don't need to mess with tests in 2.6/3.1, but everything should pass under 2.7 and 3.2. New version of the patch for 3.1 optin-hash-randomization-for-3.1-dmalcolm-2012-01-28-001.patch This version adds a command-line flag to enable hash-randomization: -R (given that the -E flag disables env vars and thus disabled PYTHONHASHRANDOMIZATION). See [1] below [Is there a convenient way to check the length of the usage messages in Modules/main.c? I see this comment: /* Long usage message, split into parts < 512 bytes */ ] I reworded the documentation somewhat based on input from Barry and Antoine. Also adds a NEWS item. Passes "make test" on this x86_64 Fedora 15 box, --with-pydebug, though that's without randomization enabled (it just does it within individual test cases that explicitly enable it). No performance testing done yet (though hopefully similar to that of Victor's patch; see msg151078) No idea of the impact on Windows users (I don't have a windows dev box). It still has the stuff from Victor's patch described in msg151158. How is this looking? Dave [1] IRC transcript concerning "-R" follows: <__ap__> dmalcolm: IMO it would be simpler if there was only one env var (preferably not too clumsy to type) <__ap__> also, despite being neither barry nor gutworth, I think the test suite *should* pass with randomized hashes <__ap__> :) <dmalcolm> :) <__ap__> also the failure you're having is a bit worrying, since apparently it's not about dict ordering <dmalcolm> PYTHONHASHSEED exists mostly for selftesting (also for compat, if you absolutely need to reproduce a specific random dict ordering) <__ap__> ok <__ap__> if -E suppresses hash randomization, I think we should also add a command-line flag <__ap__> -R seems untaken <__ap__> also it'll make things easier for Windows users, I think