Raymond Hettinger added the comment:
Closing this because it was never an active proposal, just more of a thought
experiment that I didn't want to lose track of.
--
resolution: - not a bug
status: open - closed
___
Python tracker
Antoine Pitrou added the comment:
Given interned strings can already be compared by pointer, I'd recommend people
call sys.intern() on their strings if they want really fast equality
comparisons.
--
nosy: +pitrou, tim.peters
___
Python tracker
Marc-Andre Lemburg added the comment:
I wouldn't make this the default, since the probability is small, but not zero.
However, it may be worth exploring this as dict sub-type for applications to
use which could benefit from it.
For internal strings, we already use interning, so no win there.
Serhiy Storchaka added the comment:
In case of class or module dicts attribute names usually are interned. So no
string comparison is needed if the key is found. It is needed only when the key
is not found, but found a key with the same hash (with the chance 5e-28). The
benefit of
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
priority: normal - low
versions: -Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23712
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23712
___
___
Stefan Behnel added the comment:
The problem is, even if the chance is excessively small, it's not zero.
Meaning, someone's data set somewhere will break somehow. And with hash
randomisation, it'll mean that the problem spotted in some life system will be
entirely unreproducible without
Josh Rosenberg added the comment:
Assuming Siphash is in fact cryptographically secure (in the sense you can't
choose a desired result hash with better odds that brute force), and it appears
to be so, with a keyspace of 64 bits, if it's evenly distributed (which a
cryptographically secure
Donald Stufft added the comment:
To be clear, I have no opinion on your specific proposal and I don't know if
the difference between cryptographically secure and not cryptographically
secure matters for it. I just wanted to be clear that with SipHash an attacker
should *not* be able to choose
Donald Stufft added the comment:
I'm not sure what you mean by Siphash isn't cryptographically secure. One of
the key points of Siphash is that it *is* cryptographically secure. It has a
smaller space than your typical hash function (MD5, SHA1, SHA2, etc) which
means that collisions
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
Added file: http://bugs.python.org/file38566/assume_perf_uni_hash1.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23712
___
New submission from Raymond Hettinger:
This tracker item is for a thought experiment I'm running where I can collect
the thoughts and discussions in one place. It is not an active proposal for
inclusion in Python.
The idea is to greatly speed-up the language for set/dict lookups of unicode
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
Removed file: http://bugs.python.org/file38565/assume_perf_uni_hash.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23712
___
13 matches
Mail list logo
