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