Am 16.01.2012 09:44, schrieb Christian Heimes:
Am 16.01.2012 09:18, schrieb Peter Otten:
I've taken a quick look into the suds source; the good news is that you have
to change a single method, reader.Reader.mangle(), to fix the problem with
hash stability.
However, I didn't see any code to deal
Am 16.01.2012 09:18, schrieb Peter Otten:
> I've taken a quick look into the suds source; the good news is that you have
> to change a single method, reader.Reader.mangle(), to fix the problem with
> hash stability.
>
> However, I didn't see any code to deal with hash collisions at all.
It sme
Heiko Wundram wrote:
> Am 15.01.2012 13:22, schrieb Peter Otten:
>> I'm curious: did you actually get false cache hits
in a suds cache
>> or just slower responses?
> It broke the application using suds, not due to false cache hits, but
> due to not getting a cache hit anymore at all.
> so ba
Chris Angelico, 15.01.2012 17:13:
> Of course, it's still dodgy to depend on the stability of something
> that isn't proclaimed stable, and would be far better to use some
> other hashing algorithm (MD5 or SHA for uberreliability).
I've seen things like MD5 or SHA* being used quite commonly for fi
Am 15.01.2012 17:13, schrieb Chris Angelico:
On Mon, Jan 16, 2012 at 3:07 AM, Heiko Wundram wrote:
I don't know the prevalence of suds, but I guess there's more people than me
using it to query SOAP-services - all of those will be affected if the
hash() output is changed. Additionally, if hash(
On Mon, Jan 16, 2012 at 3:07 AM, Heiko Wundram wrote:
> I don't know the prevalence of suds, but I guess there's more people than me
> using it to query SOAP-services - all of those will be affected if the
> hash() output is changed. Additionally, if hash() isn't stable between runs
> (the randomi
Am 15.01.2012 13:22, schrieb Peter Otten:
Heiko Wundram wrote:
I agree completely with that (I hit the corresponding problem with suds
while transitioning from 32-bit Python to 64-bit Python, where hashes
aren't stable either), but as stated in my mail: that wasn't the
original question. ;-)
I
Heiko Wundram wrote:
> Am 15.01.2012 11:13, schrieb Stefan Behnel:
>> That's a stupid design. Using a hash function that the application does
>> not control to index into persistent storage just screams for getting the
>> code broken at some point.
>
> I agree completely with that (I hit the corr
On Sun, Jan 15, 2012 at 11:03 PM, Bryan
wrote:
> Chris Angelico wrote:
>> Suggestion: Create a subclass of dict, the SecureDict or something,
>> ... there's no point adding extra load to every
>> name lookup just because of a security issue in an extremely narrow
>> situation.
>
> That seemingly "
Chris Angelico wrote:
> Suggestion: Create a subclass of dict, the SecureDict or something,
> which could either perturb the hashes or even use a proper
> cryptographic hash function; normal dictionaries can continue to use
> the current algorithm. The description in Objects/dictnotes.txt
> suggest
Am 15.01.2012 11:13, schrieb Stefan Behnel:
That's a stupid design. Using a hash function that the application does not
control to index into persistent storage just screams for getting the code
broken at some point.
I agree completely with that (I hit the corresponding problem with suds
while
Heiko Wundram, 14.01.2012 23:45:
> Am 14.01.2012 10:46, schrieb Peter Otten:
>> Steven D'Aprano wrote:
>>> How many people rely on hash(some_string) being stable across Python
>>> versions? Does anyone have code that will be broken if the string hashing
>>> algorithm changes?
>>
>> Nobody who under
On 1/14/2012 9:26 PM, Roy Smith wrote:
Steven D'Aprano wrote:
How many people rely on hash(some_string) being stable across Python
versions? Does anyone have code that will be broken if the string hashing
algorithm changes?
I would never rely on something like that unless the docs unambiguo
In article <4f1107b7$0$29988$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> On the Python Dev mailing list, there is a discussion going on about the
> stability of the hash function for strings.
>
> How many people rely on hash(some_string) being stable across Python
> versions
On Sat, Jan 14, 2012 at 3:42 PM, Steven D'Aprano
wrote:
> On the Python Dev mailing list, there is a discussion going on about the
> stability of the hash function for strings.
>
> How many people rely on hash(some_string) being stable across Python
> versions? Does anyone have code that will be b
Am 14.01.2012 10:46, schrieb Peter Otten:
Steven D'Aprano wrote:
How many people rely on hash(some_string) being stable across Python
versions? Does anyone have code that will be broken if the string hashing
algorithm changes?
Nobody who understands the question ;)
Erm, not exactly true. The
Steven D'Aprano wrote:
> On the Python Dev mailing list, there is a discussion going on about the
> stability of the hash function for strings.
>
> How many people rely on hash(some_string) being stable across Python
> versions? Does anyone have code that will be broken if the string hashing
> al
17 matches
Mail list logo
