You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ERROR: test_record_no_hash (test_multiarray.TestRecord)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"X:\Python33\lib\site-packages\numpy\core\tests\test_multiarray.py",
line 2464, in test_record_no_hash
self.assertRaises(TypeError, hash, a[0])
File "X:\Python33\lib\unittest\case.py", line 570, in assertRaises
return context.handle('assertRaises', callableObj, args, kwargs)
File "X:\Python33\lib\unittest\case.py", line 135, in handle
callable_obj(*args, **kwargs)
File "X:\Python33\lib\unittest\case.py", line 153, in __exit__
self.obj_name))
TypeError: unhashable type: 'writeable void-scalar'
I [Christolph] could reproduce the weirdness outside the testsuite on 64 bit Python
3.2, 3.3 and 3.4. It looks like the interpreter gets corrupted.
It could be due to numpy 1.8 using a wrong signature for the hash
function [1] on win-amd64-py3.x. Since Python 3.2 the return value must
be of type Py_hash_t (defined as Py_ssize_t) [2], not C long as
for Python <= 3.1.
Can we call it npy_hash_t? We've run into trouble before with our py
version compatibility hacks colliding with other people's py version
compatibility hacks. Otherwise looks good to me.
On 14 Sep 2013 17:24, "Christoph Gohlke" [email protected] wrote:
This patch from last night fixes the test error and all other tests also
pass. The changes should only affect win-amd64-py3.x, where sizeof(Py_hash_t)
!= sizeof(long). I can work on a PR and backport later. Any comments in
the meantime?
/* borrowed from complex_hash _/-static long+static Py_hash_t
c@lname@_arrtype_hash(PyObject *obj)
{- long hashreal, hashimag, combined;+ Py_hash_t hashreal, hashimag, combined;
hashreal = _Py_HashDouble((double)
(((PyC@name@ScalarObject *)obj)->obval).real);
@@ -3023,13 +3023,13 @@ c@lname@_arrtype_hash(PyObject *obj)
}
/end repeat/
-static long+static Py_hash_t
half_arrtype_hash(PyObject *obj)
{
return Py_HashDouble(npy_half_to_double(((PyHalfScalarObject *)obj)->obval));
}
-static long+static Py_hash_t
object_arrtype_hash(PyObject *obj)
{
return PyObject_Hash(((PyObjectScalarObject *)obj)->obval);@@ -3038,14 +3038,14 @@ object_arrtype_hash(PyObject *obj)
/ we used to just hash the pointer /
/ now use tuplehash algorithm using voidtype_item to get the object /-static long+static Py_hash_t
void_arrtype_hash(PyObject *obj)
{- register long x, y;+ register Py_hash_t x, y;
register Py_ssize_t len, n;
register PyVoidScalarObject *p;
register PyObject *element;- long mult = 1000003L;+ Py_hash_t mult = 1000003L;
x = 0x345678L;
p = (PyVoidScalarObject *)obj;
/ Cannot hash mutable void scalars */
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3743#issuecomment-24450191
.
We should really get rid of the register modifier. Nathaniel's suggestion is good. Otherwise looks good to me. Let's hope there were no hash functions without hash in the name ;)
Activity
charris commentedon Sep 14, 2013
Fix also needs backport to 1.7.x.
njsmith commentedon Sep 14, 2013
Can we call it npy_hash_t? We've run into trouble before with our py
version compatibility hacks colliding with other people's py version
compatibility hacks. Otherwise looks good to me.
On 14 Sep 2013 17:24, "Christoph Gohlke" [email protected] wrote:
charris commentedon Sep 14, 2013
We should really get rid of the
registermodifier. Nathaniel's suggestion is good. Otherwise looks good to me. Let's hope there were nohashfunctions withouthashin the name ;)Merge pull request #3747 from cgohlke/py_hash_t
charris commentedon Sep 15, 2013
Closed by 4d53e8b.