[Python-Dev] ssize_t question: longs in header files (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Mon May 29 23:25:11 CEST 2006

Neal Norwitz wrote:

minus comments, etc yields several questions about whether some values should use Pyssizet rather than C longs. In particular:

* hash values Include/abstract.h: long PyObjectHash(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 obival;

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

More information about the Python-Dev mailing list