In http://mail.python.org/pipermail/python-dev/2012-January/116003.html
Benjamin Peterson wrote:
2. It will be off by default in stable releases ... This will prevent code breakage ...
2012/1/27 Steven D'Aprano <steve at pearwood.info>:
... it will become on by default in some future release?
On Fri, Jan 27, 2012, Benjamin Peterson <benjamin at python.org> wrote:
Yes, 3.3. The solution in 3.3 could even be one of the more sophisticated proposals we have today.
Brett Cannon (Mon Jan 30) wrote:
I think that would be good. And I would even argue we remove support for turning it off to force people to no longer lean on dict ordering as a crutch (in 3.3 obviously).
Turning it on by default is fine. Removing the ability to turn it off is bad. If regression tests fail with python 3, the easiest thing to do is just not to migrate to python 3. Some decisions (certainly around unittest, but I think even around hash codes) were settled precisely because tests shouldn't break unless the functionality has really changed. Python 3 isn't yet so dominant as to change that tradeoff. I would go so far as to add an extra step in the porting recommendations; before porting to python 3.x, run your test suite several times with hash randomization turned on; any failures at this point are relying on formally undefined behavior and should be fixed, but can *probably* be fixed just by wrapping the results in sorted. (I would offer a patch to the porting-to-py3 recommendation, except that I couldn't find any not associated specifically with 3.0) -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ