BUG: fix hashing of long integers under python3

[juliantaylor]

python3 long_hash is more complex than int_hash so instead of copying
into numpy call it via the Python capi.
Same for long long for wich the numpy hash function is not correct with
python 2.7 on i386.
Will be slower but doesn't need adapting each timy python changes.
closes #3793

[juliantaylor]

tested on amd64, i386, win32 python 2 and 3
@cgohlke can you test it on win64 with py2 and py3?

[cgohlke]

All tests pass on Windows with Python 2.7 and 3.3, 32 and 64 bit.

[njsmith]

Looks good to me
On 26 Sep 2013 21:50, "Christoph Gohlke" notifications@github.com wrote:

All tests pass on Windows with Python 2.7 and 3.3, 32 and 64 bit.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/3800#issuecomment-25202614
.

[charris]

Thanks Julian.

[juliantaylor]

I think it should it be backported to 1.8.
What about 1.7? could there be any issues produced by changing the hashing in a stable release?

[charris]

It's a bug, so probably should go into 1.7 also. What is the difference for python 2?

[njsmith]

Only issue I can think of with the stable release thing is that it might
change dict sort order, which sometimes reveals latent bugs in test suites
and things. My feeling is that ensuring correct lookup behavior is more
important.
On 27 Sep 2013 00:30, "Charles Harris" notifications@github.com wrote:

It's a bug, so probably should go into 1.7 also. What is the difference
for python 2?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/3800#issuecomment-25212260
.

[juliantaylor]

python2 is only broken on 32 bit with long long types, e.g. np.int64(-2**32)

[juliantaylor]

#3747 has not been backported to 1.8 and 1.7, this PR depends on it.

[juliantaylor]

nevermind, I forgot to pull on the maintainance branch