On Jan 05, 2012, at 10:40 PM, Christian Heimes wrote:
Hey Barry, stop stealing my ideas! :) I've argued for these default settings for days.
I've suggested the env var PYRANDOMHASH. It's easy to set env vars in Apache. For example Debian/Ubuntu has /etc/apache2/envvars.
For consistency, it really should be PYTHONSOMETHING. I personally don't care how long it is (e.g. PYTHONIOENCODING).
Settings for PYRANDOMHASH:
PYRANDOMHASH=1 enable randomized hashing function
PYRANDOMHASH=/path/to/seed enable randomized hashing function and read seed from 'seed'
PYRANDOMHASH=0 disable randomed hashing function
Why not PYTHONHASHSEED then?
Since there isn't an easy way to set env vars in a shebang line since something like
#!/usr/bin/env PYRANDOMHASH=1 python2.7
doesn't work, we could come up with a solution the shebang.
We have precedence for mirroring startup options and envars, so it doesn't bother me to add such a switch to Python 3.3. It *does* bother me to add a switch to any stable release.
IMHO the setting for the default setting should be a compile time option. It's reasonable easy to extend the configure script to support --enable-randomhash / --disable-randomhash. The MS VC build scripts can grow a flag, too.
I still think that the topic needs a PEP. A couple of days ago I started with a PEP. But Guido told me that he doesn't see a point in a PEP because he prefers a small and quick solution, so I stopped working on it. However the arguments, worries and ideas in this enormous topic have repeated over and over. We know from experience that a PEP is a great way to explain the how, what and why of the change as well as the paths we didn't take.
One way to look at it is to have a quick-and-dirty solution for stable releases. It could be suboptimal from a ui point of view because of backward compatibility issues. The PEP could then outline the boffo perfect solution for Python 3.3, which a section on how it will be backported to stable releases.