Hash stability

Heiko Wundram modelnine at modelnine.org
Sun Jan 15 11:51:12 EST 2012


Am 15.01.2012 17:13, schrieb Chris Angelico:
> On Mon, Jan 16, 2012 at 3:07 AM, Heiko Wundram<modelnine at modelnine.org>  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 randomized hash() solution which is preferred, and would also be my
>> preference), suds caching becomes completely useless. And for the results,
>> see above.
>
> Or you could just monkey-patch it so that 'hash' points to an old
> hashing function. If the current hash() is kept in builtins as (say)
> hash_320() or hash_272() or something, then anyone who wants the old
> version of the hash can still get it.

Or even easier: overwrite the default caching module (called FileCache) 
with something that implements "sensible" caching, for example by using 
the complete URL (with special characters replaced) of the DTD as a 
cache index, instead of hash()ing it. ;-)

There's "workarounds", I know - and I may be implementing one of them if 
the time comes. Again, my mail was only to point at the fact that there 
are (serious) projects out there relying on the "stableness" of hash(), 
and that these will get bitten when hash() is replaced. Which is not a 
bad thing if you ask me. ;-)

-- 
--- Heiko.



More information about the Python-list mailing list