Movatterモバイル変換
[0]ホーム
[Python-Dev] plugging the hash attack
Jim J. Jewettjimjjewett at gmail.com
Thu Feb 16 22:01:45 CET 2012
Inhttp://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 justnot to migrate to python 3. Some decisions (certainly around unittest,but I think even around hash codes) were settled precisely because testsshouldn't break unless the functionality has really changed. Python 3isn'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 withhash randomization turned on; any failures at this point are relying onformally undefined behavior and should be fixed, but can *probably* befixed just by wrapping the results in sorted.(I would offer a patch to the porting-to-py3 recommendation, except thatI 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
More information about the Python-Devmailing list
[8]ページ先頭