Message 152199 - Python tracker (original) (raw)

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 )

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 .

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__> :) :) <__ap__> also the failure you're having is a bit worrying, since apparently it's not about dict ordering 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