On Fri, May 18, 2018 at 12:15 AM, Anthony Flury via Python-Dev
wrote:
> Chris,
> I entirely agree. The same questioner also asked about the fastest data type
> to use as a key in a dictionary; and which data structure is fastest. I get
> the impression the person is very into micro-optimization, w
Chris,
I entirely agree. The same questioner also asked about the fastest data
type to use as a key in a dictionary; and which data structure is
fastest. I get the impression the person is very into
micro-optimization, without profiling their application. It seems every
choice is made based on
On Thu, May 17, 2018 at 5:21 PM, Anthony Flury via Python-Dev
wrote:
> Victor,
> Thanks for the link, but to be honest it will just confuse people - neither
> the link or the related bpo entries state that the fix is only limited to
> strings. They simply talk about hash randomization - which in m
Anthony Flury via Python-Dev wrote:
//I did suggest strongly to the original questioner that relying on the
same hash value across different platforms wasn't a clever solution
Even without randomisation, I wouldn't rely on hash values
staying the same between different Python versions. Storing
Victor,
Thanks for the link, but to be honest it will just confuse people -
neither the link or the related bpo entries state that the fix is only
limited to strings. They simply talk about hash randomization - which in
my opinion implies ALL hash algorithms; which is why I asked the question.
Hi,
String hash is randomized, but not the integer hash:
$ python3.5 -c 'print(hash("abc"))'
-8844814677999896014
$ python3.5 -c 'print(hash("abc"))'
-7757160699952389646
$ python3.5 -c 'print(hash(1))'
1
$ python3.5 -c 'print(hash(1))'
1
frozenset hash is combined from values of the set. So it
On 2018-05-16 18:10, Raymond Hettinger wrote:
>
>
>> On May 16, 2018, at 5:48 PM, Anthony Flury via Python-Dev
>> wrote:
>>
>> However the frozen set hash, the same in both cases, as is the hash of the
>> tuples - suggesting that the vulnerability resolved in Python 3.3 wasn't
>> resolved acr
> On May 16, 2018, at 5:48 PM, Anthony Flury via Python-Dev
> wrote:
>
> However the frozen set hash, the same in both cases, as is the hash of the
> tuples - suggesting that the vulnerability resolved in Python 3.3 wasn't
> resolved across all potentially hashable values.
You are correct.
This may be known but I wanted to ask this esteemed body first.
I understand that from Python3.3 there was a security fix to ensure that
different python processes would generate different hash value for the
same input - to prevent denial of service based on crafted hash conflicts.
I opened t
