<br><div class="gmail_quote">On Tue, Jan 17, 2012 at 12:59 PM, "Martin v. Löwis" <span dir="ltr"><<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd like to propose a different approach to seeding the string hashes:<br>
only do so for dictionaries involving only strings, and leave the<br>
tp_hash slot of strings unchanged.<br>
<br>
Each string would get two hashes: the "public" hash, which is constant<br>
across runs and bugfix releases, and the dict-hash, which is only used<br>
by the dictionary implementation, and only if all keys to the dict are<br>
strings. In order to allow caching of the hash, all dicts should use<br>
the same hash (if caching wasn't necessary, each dict could use its own<br>
seed).<br>
<br>
There are several variants of that approach wrt. caching of the hash<br>
1. add an additional field to all string objects, to cache the second<br>
hash value.<br></blockquote><div><br></div><div>yuck, our objects are large enough as it is.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
a) variant: in 3.3, drop the extra field, and declare that hashes<br>
may change across runs<br></blockquote><div><br></div><div>+1 Absolutely. We can and should make 3.3 change hashes across runs (behavior that can be disabled via a flag or environment variable).</div><div><br></div><div>
I think the issue of doctests and such breaking even in 2.7 due to hash order changes is a being overblown. Code like that has already needs to fix its tests at least once when they want tests to pass on on both 32-bit and 64-bit python VMs (they have different hashes). Do we have _any_ measure of how big a deal this will be before going too far here?</div>
<div><br></div><div>-gps</div></div>