<br><br><div class="gmail_quote">On Fri, Jan 13, 2012 at 5:58 PM, Gregory P. Smith <span dir="ltr">&lt;<a href="mailto:greg@krypto.org">greg@krypto.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><div class="gmail_quote"><div><div class="h5">On Fri, Jan 13, 2012 at 5:38 PM, Guido van Rossum <span dir="ltr">&lt;<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div class="gmail_quote">On Fri, Jan 13, 2012 at 5:17 PM, Antoine Pitrou <span dir="ltr">&lt;<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




On Thu, 12 Jan 2012 18:57:42 -0800<br>
<div>Guido van Rossum &lt;<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>&gt; wrote:<br>
</div><div>&gt; Hm... I started out as a big fan of the randomized hash, but thinking more<br>
&gt; about it, I actually believe that the chances of some legitimate app having<br>
&gt; &gt;1000 collisions are way smaller than the chances that somebody&#39;s code will<br>
&gt; break due to the variable hashing.<br>
<br>
</div>Breaking due to variable hashing is deterministic: you notice it as<br>
soon as you upgrade (and then you use PYTHONHASHSEED to disable<br>
variable hashing). That seems better than unpredictable breaking when<br>
some legitimate collision chain happens.</blockquote></div><br></div>Fair enough. But I&#39;m now uncomfortable with turning this on for bugfix releases. I&#39;m fine with making this the default in 3.3, just not in 3.2, 3.1 or 2.x -- it will break too much code and organizations will have to roll back the release or do extensive testing before installing a bugfix release -- exactly what we *don&#39;t* want for those.<br>




<br>FWIW, I don&#39;t believe in the SafeDict solution -- you never know which dicts you have to change.<div><div><br clear="all"></div></div></blockquote><div><br></div></div></div><div>Agreed.</div><div><br>
</div><div>Of the three options Victor listed only one is good.</div><div><br></div><div>I don&#39;t like <i>SafeDict</i>.  <b>-1</b>.  It puts the onerous on the coder to always get everything right with regards to data that came from outside the process never ending up hashed in a non-safe dict or set *anywhere*.  &quot;Safe&quot; needs to be the default option for all hash tables.</div>


<div><br></div><div>I don&#39;t like the &quot;<i>too many hash collisions</i>&quot; exception. <b>-1</b>. It provides non-deterministic application behavior for data driven applications with no way for them to predict when it&#39;ll happen or where and prepare for it. It may work in practice for many applications but is simply odd behavior.</div>


<div><br></div><div>I do like <i>randomly seeding the hash</i>. <b>+1</b>. This is easy. It can easily be back ported to any Python version.</div><div><br></div><div>It is perfectly okay to break existing users who had anything depending on ordering of internal hash tables. Their code was already broken. We <b>will</b> provide a flag and/or environment variable that can be set to turn the feature off at their own peril which they can use in their test harnesses that are stupid enough to use doctests with order dependencies.</div>

</div></blockquote><div><br></div><div>What an implementation looks like:</div><div><br></div><div> <a href="http://pastebin.com/9ydETTag">http://pastebin.com/9ydETTag</a></div><div> </div><div>some stuff to be filled in, but this is all that is really required.  add logic to allow a particular seed to be specified or forced to 0 from the command line or environment.  add the logic to grab random bytes.  add the autoconf glue to disable it.  done.</div>

<div><br></div><div>-gps</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<div><br></div><div>This approach worked fine for Perl 9 years ago.  <a href="https://rt.perl.org/rt3//Public/Bug/Display.html?id=22371" target="_blank">https://rt.perl.org/rt3//Public/Bug/Display.html?id=22371</a></div>

<span class="HOEnZb"><font color="#888888"><div><br></div><div>
-gps</div></font></span></div>
</blockquote></div><br>