Am 28.10.2013 16:18, schrieb Serhiy Storchaka:
> Christian, why PY_HASH_EXTERNAL is here? Do you plan use it any official build? I think that in custom build of Python whole files pyhash.c and pyhash.h can be replaced.

Because you can't simple replace the files. It also contains
_Py_HashBytes() and  _PyHash_Fini(). With PY_HASH_EXTERNAL embedders can
simply define PY_HASH_ALGORITHM PY_HASH_EXTERNAL and provide the extern
struct inside a separate object file.

> When you will get rid from PY_HASH_EXTERNAL, then you could get rid from PyHash_FuncDef, PyHash_Func, etc.

I don't understand why you want me to get rid of the struct. What's your
argument against the struct? I like the PyHash_FuncDef because it groups
all information (func ptr, name, hash metadata) in a single structure.

> Why _Py_HashDouble() and _Py_HashPointer() are moved to pyhash.c? They are hash algorithm agnostic, and it is unlikely they will be redefined in custom build.

I have moved the functions to pyhash.c in order to keep all related
internal function in one file. They do not belong in Objects/object.c.

> You not need the HAVE_ALIGNED_REQUIRED macros if use PY_UHASH_CPY (or something like for exact 64 bit) in siphash24. On platforms where aligned access is required you will use per-bytes copy, otherwise you will use fast 64-bit copy.

I'm not going to make siphash24 compatible with platforms that require
aligned memory for integers. It's an unnecessary complication and
slow-down for all common platforms. The feature will simply not be
available on archaic architectures.

Seriously, nobody gives a ... about SPARC and MIPS. :) It's nice that
Python still works on these CPU architectures. But I neither want to
deviate from the SipHash24 implementation nor make the code slower on
all relevant platforms such as X86 and X86_64.