On Sat, Aug 28, 2010 at 3:12 PM, Hanno Schlichting <ha...@hannosch.eu> wrote:
> On Sat, Aug 28, 2010 at 8:47 PM, Jim Fulton <j...@zope.com> wrote:
>> On Sat, Aug 28, 2010 at 12:17 PM, Hanno Schlichting <ha...@hannosch.eu>
>>> I've recently stumbled on some at least to me unexpected behavior with
>> Specifically, zope.keyreference.persistent, I assume.
>>> 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
If someone has the energy, I think it's worth trying to report this as a
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -