[Zope-dev] zope.keyreference hashes vs. 32/64bit

[Jim Fulton]

On Sat, Aug 28, 2010 at 3:12 PM, Hanno Schlichting <hanno at hannosch.eu> wrote:
> Hi.
>
> On Sat, Aug 28, 2010 at 8:47 PM, Jim Fulton <jim at zope.com> wrote:
>> On Sat, Aug 28, 2010 at 12:17 PM, Hanno Schlichting <hanno at hannosch.eu> wrote:
>>> I've recently stumbled on some at least to me unexpected behavior with
>>> zope.keyreference.
>>
>> Specifically, zope.keyreference.persistent, I assume.
>
> Yes.
>
>>> Does anyone else see a problem with this? Should keyreference use a
>>> different hash algorithm?
>>
>> Potentially, yes.  In current practice, I don't think so.
>>
>> When a key reference is uses as a BTree key, its comparison function,
>> rather than it's hash is used.
>>
>> If a key reference hash was used as a persistent key, then this would
>> definitely be a problem.
>>
>> Note that in a dictionary or PersistentMapping, the hash isn't
>> saved persistently. The object is saves as a collection of items and the
>> hashes are recomputed on unpickling.
>
> Ah right. This makes it less likely to be a problem in practice.
>
>> I'm in favor of someone coming up with a stable hash to
>> avoid future pitfalls.
>>
>> It's sad that Python's hash isn't stable across Python versions
>> and architectures. Is this documented? If so, It's a missfeature.
>> If not, perhaps it should be reported as a bug.
>
> The official Python documentation doesn't specify anything explicitly,
> but it also doesn't describe the algoritm or state that it's stable.
>
> You do immediately find http://effbot.org/zone/python-hash.htm
> googling for "python hash" though. This notes that the algorithm
> changed in Python 2.4. Looking at the NEWS file of Python, the hash
> algorithm has again changed in Python 3.2 alpha 1 referencing issue
> 8188.

If someone has the energy, I think it's worth trying to report this as a
bug. :)

Jim


-- 
Jim Fulton