RetroSearch Browse

Fri Jan 6 11:01:28 CET 2012 · http://mail.python.org/pipermail/python-dev/2012-January/115352.html

Glenn Linderman wrote:
> On 1/5/2012 5:52 PM, Steven D'Aprano wrote:
>>
>> At some point, presuming that there is no speed penalty, the behaviour 
>> will surely become not just enabled by default but mandatory. Python 
>> has never promised that hashes must be predictable or consistent, so 
>> apart from backwards compatibility concerns for old versions, future 
>> versions of Python should make it mandatory. Presuming that there is 
>> no speed penalty, I'd argue in favour of making it mandatory for 3.3. 
>> Why do we need a flag for something that is going to be always on? 
> 
> I think the whole paragraph is invalid, because it presumes there is no 
> speed penalty.  I presume there will be a speed penalty, until 
> benchmarking shows otherwise.

There *may* be a speed penalty, but I draw your attention to Paul McMillian's 
email on 1st of January:

     Empirical testing shows that this unoptimized python
     implementation produces ~10% slowdown in the hashing of
     ~20 character strings.

and Christian Heimes' email on 3rd of January:

     The changeset adds the murmur3 hash algorithm with some
     minor changes, for example more random seeds. At first I
     was worried that murmur might be slower than our old hash
     algorithm. But in fact it seems to be faster!

So I think that it's a fairly safe bet that there will be a solution that is 
as fast, or at worst, trivially slower, than the current hash function. But of 
course, benchmarks will be needed.

-- 
Steven

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2012-January/115352.html below:

[Python-Dev] Hash collision security issue (now public)