RetroSearch Browse

Mon May 29 23:25:11 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-May/065378.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-May/065378.html below:

[Python-Dev] ssize_t question: longs in header files