RetroSearch Browse

Fri Oct 4 00:44:25 CEST 2013 · https://mail.python.org/pipermail/python-dev/2013-October/129154.html

03.10.13 23:47, Guido van Rossum написав(ла):
> On Thu, Oct 3, 2013 at 12:55 PM, Christian Heimes <christian at python.org
> <mailto:christian at python.org>> wrote:
>
>     Am 03.10.2013 21:45, schrieb Guido van Rossum:
>      > But fixing that shouldn't need all the extra stuff you're
>      > proposing.
>
>     I have proposed some of the extra stuff for more flexibility, the rest
>     is for testing and debugging.
>
>
> Hm, I don't think we need more infrastructure for this. As Antoine said,
> if you're hacking on this you might as well edit the source.

What we could do is to move all hash-related stuff into separated .c and 
.h files.

>      > SipHash: more secure and about same speed on most systems
>      >
>      > Same speed as what?
>
>     Same speed as the current algorithm in Python 3.3 and earlier.
>
>
> OK, then I have no objection to switching to it, *if* the security issue
> is really worth fixing. Otherwise it would be better to look for a hash
> that is *faster*, given your assertion that the current hash is inefficient.

Actually same speed only for UCS1 string. For UCS2 and UCS4 strings it 
can be 5x to 10x slower [1]. But I don't known how it affects real programs.

[1] http://bugs.python.org/issue14621#msg175048

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

Showing content from https://mail.python.org/pipermail/python-dev/2013-October/129154.html below:

[Python-Dev] Make str/bytes hash algorithm pluggable?