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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
