Neal Norwitz wrote: > minus comments, etc yields several questions about whether some > values should use Py_ssize_t rather than C longs. In particular: > > * hash values > Include/abstract.h: long PyObject_Hash(PyObject *o); // also in > object.h > Include/object.h:typedef long (*hashfunc)(PyObject *);
I don't think these should be Py_ssize_t. Of course, a pointer type cannot naturally convert to a long on some systems, so where we use a pointer as a hash, we should do so carefully if sizeof(void*) > sizeof(long); an xor of low and high word is probably good enough. Currently, the code does something way more complex (actually creating a long object); that should be replaced either by inlining long_hash, or by using an even simpler hash function for 64-bit pointers. > * ints: Include/intobject.h: long ob_ival; As Tim says, this is way out of scope for 2.5. Guido said it is ok to change this to 64-bit ints in 2.6, but I expect some embedded system developers will start screaming when they hear that: 64-bit arithmetic is expensive on a 32-bit machine. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
